[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Dependency loops considered harmful?



Matthew Woehlke wrote:
> Toshio Kuratomi wrote:
>> Uhm... you realize that building an rpm every time you want to test a
>> change as you develop an app is incredibly clunky?  It really is not
>> going to happen.  Really.
> 
> I still submit that this itself is a problem that should be worked on...
> Why must it be "too clunky"? Why can't we fix it so that expecting
> developers to install via rpm, even for incremental builds, is perfectly
> reasonable?

Here's the workflow:
cvs co web-app
cd web-app
vim web-app.cfg
./start-web-app
[hit web app in browser to make sure it runs]
^C
vim web-app/do-something.py
vim web-app/templates/do-something-page.html
./start-web-app
[hit web-app in browser and find there's a problem]
^C
vim TODO
[write note to fix this as you've got to get some sleep, go to work,
walk the dog, make dinner, kiss your wife, yum update, yum erase
openoffice, yum install nethack, play nethack, go to sleep, get up and....]
cat TODO
vim web-app/do-something.py
./start-web-app
[hit web-app in browser and find there's a problem]
[wash rinse repeat]

Now here's the same workflow with rpm building in there::
cvs co web-app
cd web-app
vim web-app.cfg
python setup.py sdist
mv dist/web-app-0.0.tar.gz ..
cd ..
rpmbuild -ba web-app.spec
sudo rpm -Uvh web-app-0.0-0.noarch.rpm
sudo /etc/init.d/web-app start
[hit web app in browser to make sure it runs]
cd web-app
vim web-app/do-something.py
vim web-app/templates/do-something-page.html
python setup.py sdist
mv dist/web-app-0.0.tar.gz ..
cd ..
vim web-app.spec
rpmbuild -ba web-app.spec
sudo rpm -e web-app
sudo rpm -Uvh web-app-0.0-1.noarch.rpm
sudo /etc/init.d/web-app start
[hit web-app in browser and find there's a problem]
^C
vim TODO
[write note to fix this as you've got to get some sleep, go to work,
walk the dog, make dinner, kiss your wife, yum update, yum erase
openoffice, yum install nethack, play nethack, go to sleep, get up and....]
cat TODO
cd web-app
vim web-app/do-something.py
python setup.py sdist
mv dist/web-app-0.0.tar.gz ..
cd ..
vim web-app.spec
rpmbuild -ba web-app.spec
sudo rpm -e web-app
sudo rpm -Uvh web-app-0.0-1.noarch.rpm
sudo /etc/init.d/web-app start
[hit web-app in browser and find there's a problem]
[wash rinse repeat]


> Of course this process probably won't involve going through
> a full rpmbuild, just something that tracks the installed files in rpm's
> database along with updating the database for dependencies (i.e. it
> would replace 'make install' but not 'make all').
>
This is definitely not what rpm is designed to do.

You could probably write a script that did it but you'd have to hook it
up to all the dependency generating scripts and do minimal parsing of
the spec file to get manually specified deps and you'd still have to
work out how to do the make install step cleanly.... I don't see much
return on investment here but YMMV.

>>>> That could mean rpm (since rpm is
>>>> responsible for taking the package and turning it into files on the
>>>> filesystem) or that could mean yum since yum is the one that actually
>>>> knows whether a package is being installed due to depsolving or user
>>>> request.  Doing this at a higher level means that information gets lost
>>>> (for instance, if you do this in PackageKit, there won't be any
>>>> information about what anaconda chose to install due to chckboxes being
>>>> clicked and which things were installed due to dependencies).
>>> All the RPM database needs to do is store a single lousy bit of
>>> information per package. The "is a dep" flag. Presumably installing
>>> packages directly with rpm would not set this flag.
>>
>> s/not// to match the behaviour you say aptitude has.
> 
> Eh? I would think that 'rpm -Uvh <some-package>' should result in
> <some-package> being flagged as a non-candidate-for-culling (unless rpm
> is told otherwise). IOW, if I hand-installed some rpm, I don't want it
> auto-culled. Maybe there is some miscommunication?
> 
Possibly.  I interpret the "is a dep flag" to mean package Foo was
installed as a dep of package Bar.  Therefore, when package Foo is
uninstalled, packages that depend on Bar and have "is a dep" set would
be uninstalled.

-Toshio

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]