Roberto Ragusa <mail@xxxxxxxxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
