| 1 |
Am Sonntag, den 04.04.2010, 23:44 -0700 schrieb Brian Harring: |
| 2 |
> On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote: |
| 3 |
> > Unconditionally removing libraries (instead of preserving them) and making |
| 4 |
> > their reverse runtime dependencies reinstalled is unacceptable because |
| 5 |
> > "emerge" process involving multiple packages is not atomic. Simple as that. |
| 6 |
> > Is this what you suggest? Correct me if I'm wrong: |
| 7 |
> > 1. Users wants to uninstall or reinstall package, we let him do it provided |
| 8 |
> > reverse runtime dependencies are satisfied afterwards. Let's say he wants to |
| 9 |
> > upgrade expat. |
| 10 |
> > 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime |
| 11 |
> > reverse deps will still be satisfied when we upgrade. |
| 12 |
> > 3. Expat has been upgraded sucessfully, |
| 13 |
> > 4a. "emerge" discovers reverse runtime dependencies are broken and it starts |
| 14 |
> > to rebuild them, then it bails out due to error ld: libexpat.so.<sth> not |
| 15 |
> > found. Because step 3 cannot be rolled back (no atomicy) - game over. |
| 16 |
> > or |
| 17 |
> > 4b. "emerge does not discover those and does nothing. python is broken so |
| 18 |
> > emerge cannot be used anymore. Game over |
| 19 |
> |
| 20 |
> This is called 'nondeterministic resolution'- known issue also w/ |
| 21 |
> proposals of that sort. |
| 22 |
> |
| 23 |
> Pretty much everytime someone proposes it as a solution, it gets |
| 24 |
> smacked down by most folk since an emerge -p invocation that is a |
| 25 |
> single pkg upgade shouldn't be able to go rebuild your entire world. |
| 26 |
> |
| 27 |
> The alternative is a slotted ABI var- basically a counter (although it |
| 28 |
> doesn't have to be) w/in ebuilds themselves to indicate if they're |
| 29 |
> carrying a new ABI from upstream for that slotting. For example, |
| 30 |
> you've got EXPAT merged w/ ABI=2, version 2.0. version 2.0.1, for |
| 31 |
> whatever reason, breaks ABI- thus v2.0.1 in the tree is ABI=2.0.1 (or |
| 32 |
> 3, as said it's an arbitrary value). |
| 33 |
> |
| 34 |
> Via that, the resolver can see that a rebuild is necessary and plan a |
| 35 |
> rebuild of all consumers (whether NEEDED based or revdep). Note |
| 36 |
> preserve-lib would be rather useful here- specifically holding onto |
| 37 |
> the intermediate lib while doing rebuilding. |
| 38 |
No, it doesn't help since you may have the same problems some people try |
| 39 |
to solve in this thread. |
| 40 |
|
| 41 |
> This however breaks down |
| 42 |
> a bit when the ABI change is in reverse of normal versioning. |
| 43 |
How so? Such a var should just specify the ABI and the PM only has to |
| 44 |
check whether it changed from one PVR to the other. The "how" is |
| 45 |
completely irrelevant. |
| 46 |
|
| 47 |
|
| 48 |
-- |
| 49 |
Tiziano Müller |
| 50 |
Gentoo Linux Developer |
| 51 |
Areas of responsibility: |
| 52 |
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor |
| 53 |
E-Mail : dev-zero@g.o |
| 54 |
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 |
Archives