On 3/14/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Friday 14 March 2008, Alec Warner wrote: > > On 3/14/08, Mike Frysinger <[EMAIL PROTECTED]> 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 ...). > > -mike > >
[-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. -- gentoo-portage-dev@lists.gentoo.org mailing list
