On Thu, 29 May 2008 11:02:55 +0200
flameeyes@... (Diego 'Flameeyes' Pettenò) wrote:

> Marius Mauch <genone@g.o> writes:
> 
> As much as we want preserve-libs to be an all-curing magic, it's
> not. When you need to replace a library you need to do so _for all its
> users at once_, if you allow it to be gradually you're opening the
> hellgate of symbol collision.

That's what `emerge @preserved-rebuild` does, or do you mean something
different?

> My solution would be to disallow _building_ anything that is or
> depends directly or indirectly on a package on the set until it is
> removed, or at the request of merging "mickeymouse", depending on
> "bar", re-emerging libfoo first, and bar if the user is not using
> --as-needed (checking the NEEDED lines).

Well, with preserve-libs the situation is this (using your example):
- user upgrades expat, portage keeps libexpat.so.0 around
(some packages might now be linked against both versions if the session
included other packages as well)
- emerge tells the user to rebuild all affected packages (affected =
contains libexpat.so.0 in NEEDED, so includes both libfoo and bar) by
using `emerge @preserved-rebuild` (in the future this could also be done
automatically, but that won't be before 2.2 final)
- when all affected packages have been rebuilt (so their NEEDED entries
don't contain libexpat.so.0 anymore) libexpat.so.0 is automatically
removed

So, if I understand you correctly (probably not), you want portage to
prevent the user from building any packages depending on any affected
package before the last step is completed?

> With all due respect to everybody, the right course of action here has
> to be selected by people who knows how the runtime linker works,
> symbol collision and all the rest, as that's what's at stake here.

Whoever that is is welcome to voice his opinion here, that's the point
of this thread after all.

Marius
--
gentoo-dev@g.o mailing list