William Hubbs posted on Sat, 22 Aug 2009 15:52:54 -0500 as excerpted: > On Sat, Aug 22, 2009 at 08:39:47PM +0100, Ciaran McCreesh wrote: >> We also need to consider whether people even want it done exactly the >> way Portage does it now. Some developers have expressed a preference >> for a package.mask.d of some kind instead. > > I saw that, and I'm not sure why they suggested changing the directory > from package.mask to package.mask.d, since all you would need to do is > rename the file package.mask to something like package.mask/oldmasks and > the masks in it would be preserved until you put them in different files > in the package.mask directory and removed them from oldmasks, ultimately > deleting oldmasks.
The (one) idea is to keep package.mask as a file for old package managers that don't know about package.* as a directory yet. Moving package.mask (the file) to package.mask/oldmasks wouldn't accomplish that. The scenario people are worried about, is where (for example) someone has gone away for their year's service (or two, or whatever) that some nations have, and comes back and tries to upgrade, only to find the tree is so changed that as soon as they sync, their old package manager is broken, to the point they can't use use it to upgrade to a new version, in ordered to be able to upgrade everything else! Actually splitting the current single file into multiple files isn't really a problem, and would probably be done at the same time package.mask (.d) is made a directory, all in the same commit, so it's nothing to worry about. That said, in this particular instance, I don't believe that should be a big problem. Why? Because portage has supported it for years already, and anyone using a PM that doesn't currently support it has by definition already demonstrated they are reasonably active about their Gentoo based system management choices, and thus isn't likely to let a system go unsynced and the PM unupdated for greater than say 90 days anyway. Thus, when the policy is approved by council, stick a 90-180 day hold on changing old profiles in the tree, and be done with it. So ancient PMs shouldn't be a problem either way, here. Which leaves only a simple bikeshedding issue, whether people prefer keeping the names we have, or switching to the *.d forms in keeping with the pattern used for all those /etc/*.d directories, of which a quick ls here demonstrated there's about double the number I expected, having never actually counted them before. While I'd vote for sticking with what we have, that /is/ just bikeshedding, and I REALLY want to just get on with it, regardless of what it's named, as the feature really is quite useful. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
