FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-03-2010, 10:38 AM
Maciej Mrozowski
 
Default More reliable hiding preserved libraries

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").

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.
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").

Thoughts?

1. https://bugs.gentoo.org/show_bug.cgi?id=240323
2. https://bugs.gentoo.org/show_bug.cgi?id=307391

--
regards
MM
 
Old 04-03-2010, 10:46 AM
Brian Harring
 
Default More reliable hiding preserved libraries

On Sat, Apr 03, 2010 at 12:38:17PM +0200, Maciej Mrozowski wrote:
> 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).

When I've tried experimenting w/ this I've had zero luck in
intercepting lib loadup on that one.

~harring
 
Old 04-03-2010, 10:56 AM
Fabian Groffen
 
Default More reliable hiding preserved libraries

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
 

Thread Tools




All times are GMT. The time now is 09:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org