| 1 |
On Tue, 6 Aug 2013 18:41:59 +0100 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
|
| 4 |
> On Tue, 6 Aug 2013 13:05:07 -0400 |
| 5 |
> Alexis Ballier <aballier@g.o> wrote: |
| 6 |
> > 'occasional unnecessary rebuild' is a big deal since subslots |
| 7 |
> > introduce this regression... |
| 8 |
> |
| 9 |
> Er, no. Subslots just simplify the way accurate slot dependencies are |
| 10 |
> expressed. That's all they are: an alternative to having a larger |
| 11 |
> number of (full) slots plus blockers between some of those slots. |
| 12 |
|
| 13 |
hmmm... no ? |
| 14 |
|
| 15 |
> > > There's an easy fix for that: split the package up. |
| 16 |
> > |
| 17 |
> > Great, please start submitting patches at our thousands of upstreams |
| 18 |
> > so that their packages can be split properly. |
| 19 |
> |
| 20 |
> You don't need to patch anything... You just make poppler-stable |
| 21 |
> and poppler-dodgy ebuilds. |
| 22 |
|
| 23 |
And you need to patch it to do it properly. Or you can do |
| 24 |
parts/subpackages or subslot dictionaries to express that. Proper |
| 25 |
splitting is easy to ask but harder to do in practice; you're starting |
| 26 |
to make me believe you're only on the PM writing side without much |
| 27 |
experience on how real life packages are. |
| 28 |
|
| 29 |
> > Then submit patches to run preserve-libs as soon as possible as I |
| 30 |
> > suggested in the part you cut. preserve-libs, in contrast to just |
| 31 |
> > removing the .so, leaves you with a working system in 90% of the |
| 32 |
> > cases. |
| 33 |
> |
| 34 |
> preserve-libs is broken by design. Tweaking when it's run won't fix |
| 35 |
> that breakage. |
| 36 |
> |
| 37 |
> > Exercise: Try to update a FreeBSD 6 system (libc.so.6) to a FreeBSD |
| 38 |
> > 7 system (libc.so.7) without some kind of preserve-libs mechanism. |
| 39 |
> > Been there, done that. The flaws of preserve-libs show up but it |
| 40 |
> > maintains a half working system all the way long that allows you to |
| 41 |
> > finish the update. |
| 42 |
> |
| 43 |
> There is no "half working". Something is either correct or it isn't. |
| 44 |
|
| 45 |
Sometimes there is no 'correct'. You are probably using every day |
| 46 |
programs that use heuristics/approximations to solve NP-hard or |
| 47 |
undecidable problems in a 'correct enough' way. |
Archives