Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]

On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote:
> Unconditionally removing libraries (instead of preserving them) and making 
> their reverse runtime dependencies reinstalled is unacceptable because 
> "emerge" process involving multiple packages is not atomic. Simple as that.
> Is this what you suggest? Correct me if I'm wrong:
> 1. Users wants to uninstall or reinstall package, we let him do it provided 
> reverse runtime dependencies are satisfied afterwards. Let's say he wants to 
> upgrade expat.
> 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime 
> reverse deps will still be satisfied when we upgrade.
> 3. Expat has been upgraded sucessfully,
> 4a. "emerge" discovers reverse runtime dependencies are broken and it starts 
> to rebuild them, then it bails out due to error ld: libexpat.so.<sth> not 
> found. Because step 3 cannot be rolled back (no atomicy) - game over.
> or
> 4b. "emerge does not discover those and does nothing. python is broken so 
> emerge cannot be used anymore. Game over

This is called 'nondeterministic resolution'- known issue also w/ 
proposals of that sort.

Pretty much everytime someone proposes it as a solution, it gets 
smacked down by most folk since an emerge -p invocation that is a 
single pkg upgade shouldn't be able to go rebuild your entire world.

The alternative is a slotted ABI var- basically a counter (although it 
doesn't have to be) w/in ebuilds themselves to indicate if they're 
carrying a new ABI from upstream for that slotting.  For example, 
you've got EXPAT merged w/ ABI=2, version 2.0.  version 2.0.1, for 
whatever reason, breaks ABI- thus v2.0.1 in the tree is ABI=2.0.1 (or 
3, as said it's an arbitrary value).

Via that, the resolver can see that a rebuild is necessary and plan a 
rebuild of all consumers (whether NEEDED based or revdep).  Note 
preserve-lib would be rather useful here- specifically holding onto 
the intermediate lib while doing rebuilding.  This however breaks down 
a bit when the ABI change is in reverse of normal versioning.

Usually whenever I've floated this idea, it's gotten smacked down by 
devs due to the extra work it may entail- someone doing an experiment 
on this would be rather useful (someone with a tinderbox 
specifically).

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]