IMO the package mask file should be gone when Portage is rewritten. 1. It's inefficient to parse the entire 700+ line file just to determine maskedness of one package. 2. Users that use rsync to synchronise can't keep packages permanently unmasked. 3. Users that use CVS or anonCVS to synchronise get collisions in the file. 4. Because the file is so large, it's easy to screw it up by having multiple entries which conflict or some such. Instead, I propose allowing an *optional* file named "MASK" (or whatever) in the ebuild directory of each package. This way it would be easy to see what versions of the package are masked, if any, right from the ebuild directory for that package.
Hi Arcady Please take a look at #1523 http://bugs.gentoo.org/show_bug.cgi?id=1523 First part of it (for which I already provided some code) introduces ebuild stability levels. This can be used to do just what you want (and many more). Eventually I think we should shift to new ebuild processing model and the fact you come up with the suggestion similar to the first part of mine gives me at least some feedback :). Should I say I will appreciate more specific comments as well? ;) BTW, should this bug be marked as a duplicate of #1523? George
added myself to CC
stability levels sounds good to me .. hmm.. what about a MASK directory with extra files for each category? (maybe xml or just simple text) greetings
Please add a "mask_overlay"/pinning mechanism then, including a tool to add, remove and get status reports of package masks too, to deal with it in a transparent way. I guess, I'm not the only one who misses a local overlay for the package mask file. I made a simple script for myself for this purpose, but adding the own lines every time after syncing to package.mask is not the way it should work.
/etc/portage/package.mask /etc/portage/package.unmask ACCEPT_KEYWORDS