| 1 |
On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote: |
| 2 |
> Unconditionally removing libraries (instead of preserving them) and making |
| 3 |
> their reverse runtime dependencies reinstalled is unacceptable because |
| 4 |
> "emerge" process involving multiple packages is not atomic. Simple as that. |
| 5 |
> Is this what you suggest? Correct me if I'm wrong: |
| 6 |
> 1. Users wants to uninstall or reinstall package, we let him do it provided |
| 7 |
> reverse runtime dependencies are satisfied afterwards. Let's say he wants to |
| 8 |
> upgrade expat. |
| 9 |
> 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime |
| 10 |
> reverse deps will still be satisfied when we upgrade. |
| 11 |
> 3. Expat has been upgraded sucessfully, |
| 12 |
> 4a. "emerge" discovers reverse runtime dependencies are broken and it starts |
| 13 |
> to rebuild them, then it bails out due to error ld: libexpat.so.<sth> not |
| 14 |
> found. Because step 3 cannot be rolled back (no atomicy) - game over. |
| 15 |
> or |
| 16 |
> 4b. "emerge does not discover those and does nothing. python is broken so |
| 17 |
> emerge cannot be used anymore. Game over |
| 18 |
|
| 19 |
This is called 'nondeterministic resolution'- known issue also w/ |
| 20 |
proposals of that sort. |
| 21 |
|
| 22 |
Pretty much everytime someone proposes it as a solution, it gets |
| 23 |
smacked down by most folk since an emerge -p invocation that is a |
| 24 |
single pkg upgade shouldn't be able to go rebuild your entire world. |
| 25 |
|
| 26 |
The alternative is a slotted ABI var- basically a counter (although it |
| 27 |
doesn't have to be) w/in ebuilds themselves to indicate if they're |
| 28 |
carrying a new ABI from upstream for that slotting. For example, |
| 29 |
you've got EXPAT merged w/ ABI=2, version 2.0. version 2.0.1, for |
| 30 |
whatever reason, breaks ABI- thus v2.0.1 in the tree is ABI=2.0.1 (or |
| 31 |
3, as said it's an arbitrary value). |
| 32 |
|
| 33 |
Via that, the resolver can see that a rebuild is necessary and plan a |
| 34 |
rebuild of all consumers (whether NEEDED based or revdep). Note |
| 35 |
preserve-lib would be rather useful here- specifically holding onto |
| 36 |
the intermediate lib while doing rebuilding. This however breaks down |
| 37 |
a bit when the ABI change is in reverse of normal versioning. |
| 38 |
|
| 39 |
Usually whenever I've floated this idea, it's gotten smacked down by |
| 40 |
devs due to the extra work it may entail- someone doing an experiment |
| 41 |
on this would be rather useful (someone with a tinderbox |
| 42 |
specifically). |
| 43 |
|
| 44 |
~harring |
Archives