| 1 |
On 03-04-2010 12:38:17 +0200, Maciej Mrozowski wrote: |
| 2 |
> Problem |
| 3 |
> |
| 4 |
> ..is known, let me summarize briefly. |
| 5 |
> |
| 6 |
> Uninstalling packages providing libraries, without checking reverse |
| 7 |
> runtime dependencies of those packages leaves their dependencies |
| 8 |
> unsatisfied (packages with broken executables and/or shared libs). |
| 9 |
> Some package managers try their best not to remove said libraries, yet |
| 10 |
> allowing packages to be removed. Those orphaned libraries cause |
| 11 |
> problems[1] as build systems of some other packages being |
| 12 |
> (re)installed afterwards pick them up and abuse those orphaned |
| 13 |
> libraries. (we don't like orphans abused, we prefer them... "gone"). |
| 14 |
|
| 15 |
Is it known why this does happen exactly? When a lib is kept because it |
| 16 |
is still used, only its soname + what the soname points to should be |
| 17 |
kept. That would mean the lib can no longer be found during linking, |
| 18 |
unless you add some trickery (or does GNU ld do something "handy" out of |
| 19 |
the box right here?). So for example: |
| 20 |
|
| 21 |
% ls |
| 22 |
usr/lib/libfoo.so -> libfoo.so.2.1 |
| 23 |
usr/lib/libfoo.so.2 -> libfoo.so.2.1 |
| 24 |
usr/lib/libfoo.so.2.1 |
| 25 |
|
| 26 |
% scanelf --soname usr/lib/libfoo.so |
| 27 |
libfoo.so.2 usr/lib/libfoo.so |
| 28 |
|
| 29 |
what should kept preserved is: |
| 30 |
|
| 31 |
usr/lib/libfoo.so.2 -> libfoo.so.2.1 |
| 32 |
usr/lib/libfoo.so.2.1 |
| 33 |
|
| 34 |
because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should |
| 35 |
(in theory and on some platforms at least) fail. |
| 36 |
|
| 37 |
> Solution |
| 38 |
> |
| 39 |
> Now, I suppose there are some ideas how to make orphaned libraries not |
| 40 |
> go in a way. Basically then need to be available for system, but |
| 41 |
> hidden for "emerge". |
| 42 |
> |
| 43 |
> There is opt-out suggestion[2], unfortunately it does not provide any |
| 44 |
> info how exactly it's supposed to be achieved. As far as |
| 45 |
> portage/pkgcore is concerned, maybe - as Brian Harring suggested - |
| 46 |
> sandbox could be used to somehow "hide" preserved libraries or |
| 47 |
> preserved library directory from ebuild environment (preserved library |
| 48 |
> directory a'ka "purgatory" - libs could be moved there when considered |
| 49 |
> orphaned). |
| 50 |
> |
| 51 |
> Opt-in suggestion is as follows: |
| 52 |
> 1. Use some library path (read by ld loader from environment) and export it |
| 53 |
> globally to environment pointing it to preserved library directory. |
| 54 |
|
| 55 |
you mean: move preserved libs to some special place and have that place |
| 56 |
being found at runtime somehow? |
| 57 |
|
| 58 |
> 2. During "emerge", unset environment variable corresponding to said |
| 59 |
> preserved library directory - orphans are no longer located. Attached |
| 60 |
> patch for glibc (2.11, but should apply to any other glibc around) and |
| 61 |
> uClibc (this one is not tested but should work as well) that makes ld |
| 62 |
> loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable. |
| 63 |
> |
| 64 |
> (LD_LIBRARY_PATH would work as well, but it's being used widely so |
| 65 |
> cannot be safely mangled.. on the second though it can - one could |
| 66 |
> filter out preserved library paths from it during "emerge"). |
| 67 |
|
| 68 |
In general, LD_LIBRARY_PATH is considered harmful, and I wouldn't like |
| 69 |
to see it being used for normal operation. |
| 70 |
|
| 71 |
Instead I'd like to know first why applications can find retained libs, |
| 72 |
because from the Portage side, in theory they shouldn't. Maybe patching |
| 73 |
GNU ld if it turns out being too smart may solve problems in a nicer way. |
| 74 |
|
| 75 |
|
| 76 |
-- |
| 77 |
Fabian Groffen |
| 78 |
Gentoo on a different level |
Archives