On 03-04-2010 12:38:17 +0200, Maciej Mrozowski wrote: > Problem > > ..is known, let me summarize briefly. > > Uninstalling packages providing libraries, without checking reverse > runtime dependencies of those packages leaves their dependencies > unsatisfied (packages with broken executables and/or shared libs). > Some package managers try their best not to remove said libraries, yet > allowing packages to be removed. Those orphaned libraries cause > problems[1] as build systems of some other packages being > (re)installed afterwards pick them up and abuse those orphaned > libraries. (we don't like orphans abused, we prefer them... "gone").
Is it known why this does happen exactly? When a lib is kept because it is still used, only its soname + what the soname points to should be kept. That would mean the lib can no longer be found during linking, unless you add some trickery (or does GNU ld do something "handy" out of the box right here?). So for example: % ls usr/lib/libfoo.so -> libfoo.so.2.1 usr/lib/libfoo.so.2 -> libfoo.so.2.1 usr/lib/libfoo.so.2.1 % scanelf --soname usr/lib/libfoo.so libfoo.so.2 usr/lib/libfoo.so what should kept preserved is: usr/lib/libfoo.so.2 -> libfoo.so.2.1 usr/lib/libfoo.so.2.1 because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should (in theory and on some platforms at least) fail. > Solution > > Now, I suppose there are some ideas how to make orphaned libraries not > go in a way. Basically then need to be available for system, but > hidden for "emerge". > > There is opt-out suggestion[2], unfortunately it does not provide any > info how exactly it's supposed to be achieved. As far as > portage/pkgcore is concerned, maybe - as Brian Harring suggested - > sandbox could be used to somehow "hide" preserved libraries or > preserved library directory from ebuild environment (preserved library > directory a'ka "purgatory" - libs could be moved there when considered > orphaned). > > Opt-in suggestion is as follows: > 1. Use some library path (read by ld loader from environment) and export it > globally to environment pointing it to preserved library directory. you mean: move preserved libs to some special place and have that place being found at runtime somehow? > 2. During "emerge", unset environment variable corresponding to said > preserved library directory - orphans are no longer located. Attached > patch for glibc (2.11, but should apply to any other glibc around) and > uClibc (this one is not tested but should work as well) that makes ld > loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable. > > (LD_LIBRARY_PATH would work as well, but it's being used widely so > cannot be safely mangled.. on the second though it can - one could > filter out preserved library paths from it during "emerge"). In general, LD_LIBRARY_PATH is considered harmful, and I wouldn't like to see it being used for normal operation. Instead I'd like to know first why applications can find retained libs, because from the Portage side, in theory they shouldn't. Maybe patching GNU ld if it turns out being too smart may solve problems in a nicer way. -- Fabian Groffen Gentoo on a different level
