Marius Mauch <[EMAIL PROTECTED]> 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/
pgpblyTC9Kg3X.pgp
Description: PGP signature
