Dependency loops considered harmful?

Toshio Kuratomi a.badger at gmail.com
Fri Sep 5 18:44:32 UTC 2008


Matthew Woehlke wrote:
> Toshio Kuratomi wrote:
>> Matthew Woehlke wrote:
>>> Current workflow:
>>> svn up
>>> make
>>> make install
>>> some-app
>>>
>>> Proposed workflow:
>>> svn up
>>> make
>>> rpm-dev-install .
>>> some-app
>>>
>>> See how painless that was? And now, rather than 'make install' littering
>>> my drive with untracked files, the helper:
>>> - rolled an incremental RPM
>>> - updated the existing package
>>>   - ...which removed any old files no longer there
>>>   - ...and added/updated any modified files
>>> - updated the rpm database to note that some-app is now installed (if it
>>> wasn't)
>>>   - ...which also means that if some-app uses libfoo-devel, rpm now
>>> knows this and won't remove libfoo-devel until I remove some-app
>>
>> The thing is you missed that in my current workflow there is no make
>> install.  So the issues you have with it dirtying up the drive don't
>> exist and all the work (or simply waiting for a package and install step
>> to finish) between the make step and invocation of some-app are extra
>> overhead.
> 
> Well, then, see my reply to Patrice, here:
> http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/91312
> 
> I'm not trying to solve the 'install-less' workflow; the benefit from
> that is IMO considerably less than the workflow *I* have, which I
> illustrated above. (In fact, the only benefit at that point is
> dependency marking. File tracking is irrelevant, and if you haven't
> installed, you aren't providing anything, so you have only one of the
> three benefits to rpm installs.)
> 
Exactly!  Which is why your solution isn't really an answer for pruning
leaf packages.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080905/964297b0/attachment.sig>


More information about the fedora-devel-list mailing list