I'd suggest to create different types of masks. Essentially, each package has a mask inside the ebuild file (KEYWORDS would become deprecated). Then you will have a masks_override file updated by rsync and another mask_override that can be freely modified by the user. The final mask is the result of the preceding three. Each mask should be accompained by its architecture. The masks should be: 1) ultra-stable (Ux86) - not recent package, but that has been throughly tested 2) stable (Sx86, currently x86) 3) beta (Bx86, currently ~x86) - seems to work but needs more testing, or some users reported lesser bugs 4) alpha (Ax86) - just in, not properly tested yet, or some users reported major bugs 5) security (!x86) - this package has security vulnerabilities emerge --pretend should report what version it wants to install and, if upgrading, what version it is installed: emerge -up openssl [ebuild U S] openssl-0.9.6k [0.9.6j !] In this case, the whole line should be in red, while updates from other packages should be in green as usual. Then, emerge should have a --mask option, like this: emerge --mask ! --update world That means "update all packages with security issues". This would be VERY handy for dialup users, that would become able to fix security issues (even using a cron command) every 24 hours without even reading the security advisories. Note that it would be very different from MASK="!x86" emerge --update world that means "update all packages to the highest version available, also using beta, alpha and security releases". Such a command would obviously be a suicide.
Cool, as this mirrors the structure I was proposing (for a bit different purpose) quite some time ago (see #1523 for example) I would not be against this (logical-wise, although there might be some infrastructure issues). Just one thing: I would rather see !x86 extended to provide general masking functionality - a.la "automated" package.mask, to bare better with this whole streamlined ebuild rocessing scheme, should this idea surface again. Besides I remember talks (long time ago :)), that package.mask was considered to be more of a transitinal, "quick and dirty" solution, so this will nicely wrap it up in a larger scheme. Also, following the -hardened mailing list I seem to recall that our security team was considering measures that would technically work as a separate pipeline (i.e. way of providing independent security upgrades) for a related ebuilds. George
security updates will be handled differently by using a XML version of GLSAs, see GLEP 14 for details. The major problem with this: how do get (positive) feedback? Both stable and stats are in unknown state, the Janitor project was dead two weeks after its start. Without feedback the whole thing won't work and even with a working feedback system I think it will only work for 10-20% of the packages. One alternative to a feedbakc system would be an automatic update tool that's changing keywords after a defined period of time, but that would create a bunch of other problems.
> Both stable and stats are in unknown state, the Janitor project was dead two weeks after > its start What do you mean? I think that using a script that automatically "promotes" masks from alpha to beta to stable to ultra-stable after a taken period of time would be simply criminal. "This program has been tested enough" is not a mathematic equation and manual updating of masks is absolutely required. At most you could use a script that makes you note "hey, you don't have received any bugs reports for N weeks. why don't you update flags?" - but that's another issue. > The major problem with this: how do get (positive) feedback? Positive feedback is absence of bug reports, that means that (a) the program is stable (b) there are so few users that use it that you really don't care :) However, this is nothing new...
*** Bug 25397 has been marked as a duplicate of this bug. ***
The two files that override masks (let's call them portage.mask for the one updated by rsync and user.mask for the user-specific one) should have the following syntax: package version(s) from_mask to_mask i.e. openoffice >=1.1-rc1,<1.1 ab s that means, "change the flag for all openoffice 1.1-RC* versions to stable, but only if they were alpha or beta." from_mask is VERY important, since without it, for example, if I modify user.mask for openoffice 1.1-rc3 setting it to stable, openoffice =1.1-rc3 s and after that a security bug is found in it, so that a line is found in portage.mask: openoffice =1.1-rc3 ! since user.mask is processed *after* portage.mask the package will be marked as stable and the user won't notice that there is a security issue. Instead, with this syntax: in portage.mask: openoffice =1.1rc3 absu ! in user.mask: openoffice =1.1rc3 ab s the mask for openoffice will not be changed by user.mask if it has become "!" after processing portage.mask.
mmh... better rename ultra-stable (U) to hardened (H), since "U" sounds like "unstable".
Shouldnt an ebuild contain information about what has happend since the last revision. f.ex. Dependency change Feature change Bugfix this way you could allow only bugfixes. And just an idea (while it is in my head) If you have package-a.b.c would you then get the bug propability by this formula? 1/((c-10)^3+b^2+a) =)
etcat -c for changelog... and for the "stability formula" that's completely useless as it varies completely between packages: some are production-stable already at version 0.2.0, while others are suicidal to use at version 6.0-SP1... :)
I think this involves too much work on behalf of the maintainers and would probably confuse the users too much.
With GELP22 in the background this will become completely unmanagable.
