| 1 |
(I think it would be better if you could post the text on the list, so people |
| 2 |
can easier cite the paragraphs they are referring to.) |
| 3 |
|
| 4 |
> I cite one situation which has actually led to system destruction: |
| 5 |
> |
| 6 |
> I was in need of a certain version of a library. A the moment I installed it |
| 7 |
> initially, this version was keyword masked for my architecture, since it was |
| 8 |
> not thoroughly tested. It worked perfectly anyway. Since it was without |
| 9 |
> issues, it became officially unmasked some time later and another version was |
| 10 |
> introduced, which was keyword masked because it didn't work at all on my |
| 11 |
> architecture. This one could be compiled, but really didn't work at all. Since |
| 12 |
> I didn't observe the new version introductions all the time, a slightly |
| 13 |
> careless world update gave me that version and left all programs depending on |
| 14 |
> the library in a non-working state. |
| 15 |
> |
| 16 |
> After all it was my fault, but on a resonably maintained system you will |
| 17 |
> always have a number of manually unmasked ebuilds, and you can't monitor them |
| 18 |
> all the time. |
| 19 |
|
| 20 |
This is why you should use exact versions in p.mask and p.unmask. If you do that |
| 21 |
you only get the minimum of masked packages, leading to minimal borkage. |
| 22 |
|
| 23 |
Now, over to the GLEP draft.. |
| 24 |
|
| 25 |
You make some very dangerous (partly wrong) assumptions in your GLEP. First of |
| 26 |
all, there's the assumption that we have the capacity to maintain such a fine |
| 27 |
graded masking scheme. We are currently mainly distinguishing between testing |
| 28 |
~arch and stable arch. I can only speak for AMD64, but we have a currently ~100 |
| 29 |
packages that wait to go into the ~amd64 tree, 54 of them for longer than 30 |
| 30 |
days. Beside that, we have about 120 packages waiting to go into the stable |
| 31 |
tree. Now, if you'd increase the number of masking "stages" from two to 10, I |
| 32 |
can guarantee that this masking scheme would get completely useless. |
| 33 |
|
| 34 |
But the far more critical assumption you make is this one: |
| 35 |
You assume that once a package has been marked stable, it keeps beeing stable. |
| 36 |
You simply can't treat every package individually. A package marked stable back |
| 37 |
in 2004 with a status level -5 should be considered ultimatively stable if I |
| 38 |
understand your proposal right. But then GCC 3.4 is marked stable too, and, oh, |
| 39 |
look, it doesn't even compile!? Things depend on each other, in a very complex |
| 40 |
fashion. Whenever some behaviour in one package is changed, it is likely to |
| 41 |
break another one. Instead of giving us 10 different status levels, show us a |
| 42 |
way to avoid such problems in general. |
| 43 |
|
| 44 |
Part of the assumption above is also the fact that these keywords do not |
| 45 |
consider the profile the user is using. A package might work great for one |
| 46 |
profile but terribly break for another (deprecated) one. |
| 47 |
|
| 48 |
You can apply the same idea to eclasses. Basically it all bails down to this: |
| 49 |
|
| 50 |
Give me 10 environments and I give you 10 different ways to break the package. |
| 51 |
|
| 52 |
Regards, |
| 53 |
|
| 54 |
-- |
| 55 |
Simon Stelling |
| 56 |
Gentoo/AMD64 Operational Co-Lead |
| 57 |
blubb@g.o |
| 58 |
-- |
| 59 |
gentoo-dev@g.o mailing list |
Archives