Re: [gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask

[Mike Frysinger]

On Saturday 15 March 2008, Alec Warner wrote:
> On 3/14/08, Mike Frysinger <vapier@g.o> wrote:
> > On Friday 14 March 2008, Alec Warner wrote:
> >  > On 3/14/08, Mike Frysinger <vapier@g.o> wrote:
> >  > > On Thursday 13 March 2008, Steve Dibb wrote:
> >  > >  > Because package.mask in CVS for profiles is so huge, I think it
> >  > >  > might help it to get organized if we split it up a bit.
> >  > >  >
> >  > >  > halcyon had a good idea for the scheme: testing, broken, removal.
> >  > >  > That seems to sum up the main 3 reason that a package would be
> >  > >  > masked.
> >  > >  >
> >  > >  > Right now there are 679 entries in package.mask.  The reason I
> >  > >  > came up with the idea was to find a way to make it easier for
> >  > >  > treecleaners to quickly see which ones they were working on.
> >  > >  >
> >  > >  > I'd like to take the discussion to -dev but wanted to get QA's
> >  > >  > thoughts first.  I haven't looked into whether or not this is
> >  > >  > technically feasible at all.
> >  > >
> >  > > i think the real solution here is allowing masking in a package
> > >
> > > You want to add a metadata key and cache it you mean?
> >
> > i dont care terribly much about the logistics, just the results.  as long
> > as an ebuild can declare itself masked, it sounds good to me.
> >
> >  this doesnt preclude the other ideas as there are often times where you
> > want to have 1 global package mask piece (like large package set bumps
> > ... so X or KDE or GNOME or ...).
>
> [-gentoo-qa, +gentoo-portage-dev]
>
> Original thread was splitting up package.mask entries.
>
> Genone notes the code to do this already is basically in already (we
> just don't invoke it for $PORTDIR/profiles afaik).
>
> Genone, do we use existing code for package.mask (ie if we switch from
> a file to  a dir will it break existing versions?  I am unsure if we
> used the directory code for $PORTDIR/profiles/*
>
> If we do then I say that is the easiest method.
>
> MIke also mentioned a means for a single ebuild to mark itself masked.
>
> I think this is useless without the use of a metadata key and I'm
> still not sold on its usefullness....I could easily buy some sort of
> bash var that is read by a tool to generate package.mask entries
> though.  Seems fragile though.

i dont see it being any different from an ebuild declaring its own KEYWORDS.  
if you want to be lazy, then have a magic KEYWORD: +pmask.
-mike