[gentoo-dev] Re: package.mask or package.mask.d

[Duncan]

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