On Thursday 13 of August 2009 12:35:43 Tiziano Müller wrote:
> Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill:
> > On Wed, 12 Aug 2009 19:46:56 +0100
> >
> > Ciaran McCreesh <ciaran.mccreesh@...> wrote:
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > >
> > > Tomáš Chvátal <scarabeus@g.o> wrote:
> > > > Also we should allow the stuff as directory thingus (portage already
> > > > handles it right).
> > >
> > > That's a seperate thing that needs EAPI control. You'll need to propose
> > > it for EAPI 4 if you want that.
> >
> > Why is that (seriously curious, not disagreeing)?  Portage has supported
> > this for quite a while now.  Does the current PMS disallow it?
> >
> > What I've really wanted for a long time is different package.mask files
> > for different types of masks.  eg.
> >
> > package.mask/broken.mask (qa.mask?)
> > package.mask/removal.mask
> > package.mask/security.mask
> > package.mask/testing.mask
> 
> To avoid collision with the current package.mask I'd prefer
> package.mask.d/ for the directory. Also makes the transition easy since
> we can generate package.mask out of the files in package.mask.d/.

package.mask.d being directory and not used internally by PM - so being just a 
convention (which may be used for manually or scripted generation of resulting 
package.mask as dev-zero proposed- it's now utilized in kde-testing overlay 
because package.mask dir used to cause paludis crashes) can be implemented 
just now with no PMS changes (since PM is supposed to ignore unknown 
files/directories in there?).

I'd suggest allowing package.mask as either directory or file though, no need 
for entities multiplying... besides the reference implementation in already 
there for ages.

-- 
regards
MM