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