Marius Mauch <genone@g.o> writes:

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

I meant something different, see the rst.
> 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

Okay this works if the user follows the procedure and tries not to bend
the rules...

> 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?

Yes this is exactly what I meant. Whenever a dependency is in the
@preserved-rebuild set, it should not be linked against. It could still
be used, but as now we don't have an easy way to distinguish between the
two, I'd say it's better to check both DEPEND and RDEPEND and disallow
its usage as a dependency until it's removed from the set.

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

(It was mostly a disclaimer so that users don't feel like they get
ignored without just cause if they want behaviour X and instead we go
with behaviour Y... I'm sure a lot of people wouldn't like the option I
proposed above, but trust me there's a reason why I voiced that concern
:) ).

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/