RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting)

[Horst H. von Brand]

Roberto Ragusa <mail at robertoragusa.it> wrote:
> Seth Vidal wrote:
> > 
> >> And how do you define "library"? There's no reliable way to
> >> distinguish them
> >> from applications.
> > 
> > This is part of the problem. It would be nice to have all things which
> > are strictly libraries add a "provides: Library something" and, of
> > course, to have all libs split from all apps.
> 
> Why should libraries be special? They are not.
> 
> Libraries dragged as dependencies are candidate for removal when
> nothing currently installed is depending on them.
> Libraries installed explicitly by the user must not be removed
> (maybe I need them for a not-packaged or manually compiled app).
> 
> s/Libraries/Apps -> same rules have to apply
> 
> Apps dragged as dependencies could be volatile, apps the user
> decided to install must stay.
> 
> Please do not limit the issue to lib/not-lib. Things are more complex
> (well, maybe they are actually simpler...)
> 
> For example:
> 
> a) wireshark-gnome (depends on wireshark)
> b) wireshark (depends on libpcap)
> c) libpcap (depends on libutilswhichsomedevelopersliketouse)
> d) libutilswhichsomedevelopersliketouse
> 
> It makes a lot of difference if a user
> 
> - has installed a) and dragged b) c) d) for dependencies
> (removing a) could try to remove everything)
> 
> or
> 
> - has installed c) and d) for own use/development, then some day
> installs a) which drags b)
> (removing a) should only try to remove b) )
> 
> - has installed c) and d) for own use/development, then some day
> installs b), then some day installs a)
> (removing a) should not try to remove anything else )
> 
> There is only one use case a little tricky:
> if I have a), which dragged b) c) and d), and now I want to
> mark b) as wanted, what should I do? maybe:
>   # yum install b)
>   To be installed:
>     none
>   To be updated:
>     none
>   To be marked as user-installed:
>     b)
>   Proceed? (y/n)
>   y
>   Operation complete.

This means the overloaded user has to remember to mark as used the stuff
she is using so it doesn't get pulled out from under her feet by deleting
unrelated packages.

What should now happen if, say, (c) gets updated, but nothing else in the
stack? What if ethereal gets renamed to wireshark? What if (c) gets
replaced upstream by a functionally equivalent, but different code base,
package? What if the whole stack gets replaced by functionally equivalent,
but API-wise completely different (and even divided into completely
different layers), stuff?


It seems to me that most of this nonsense is easy to get right with no
further effort than just creating your own RPMs and installing those,
instead of futzing around installing _systemwide_ from source.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513