[gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask
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 usefullnessI 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
Re: [gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask
On Saturday 15 March 2008, Alec Warner wrote: 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 ...). [-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 usefullnessI 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask
On Sat, 15 Mar 2008 01:34:24 -0700 Alec Warner [EMAIL PROTECTED] wrote: 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: 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/* The handling code for all package.mask files is identical, in particular they all support recursion (just search for package.mask in portage/__init__.py). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
