[gentoo-dev] QA: package.mask policies

[gentoo-dev] QA: package.mask policies

[Tomáš Chvátal]

[-- Attachment #1: Type: Text/Plain, Size: 2622 bytes --]

Hi,
since I aint got blag i will polute our lovely mailing list (sorry if i hit 
some in-middle flame :P).

Currently i've been reviewing the package.mask file (since we have to keep with 
it for a while [no package.mask folder near us :)] we have to trim it down and 
keep sane).

NOTE: The p.mask as folder situation was agreed upon so dont reply about THAT 
but focus on what follows below this point in your replies.

While i was reading it there are 5 major use cases for stuff in it.

- Masking beta/rc/alpha/development_branch stuff
- Masking live ebuild
- Masking stable releases for testing
- Masks for removal (those are quite moving in and out ;])
- Masks for security issues (mostly games)

So lets go one by one and rationalize on wether we need it or not.

* Masking beta...
This masks are good if the software release is KNOWN to break previous 
behaviour or degrade user experience. Otherwise the software should not be 
masked (its TESTING for purpose, not stable).
Also the maintainer should watch if the testing branch is still relevant (why 
on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 is 
stable ;]) and remove the branch+mask when needed.

* Masking live...
Heck no. This is not proper usage. Just use keywords mask. KEYWORDS="". 
Problem solved and the package.mask is smaller. (Note, in overlays do what 
ever you want, since it does not polute the main mask from g-x86).

* Masking stable releases...
Here i found most interesting stuff around (for example mask for testing from 
2006, yeah not ~ material after 3 years?! :P)
There should be policy defined that you can add the new release under p.mask if 
you see it fit, but the mask can stay only for 6 months (less/more, 
suggestions?) and then it must be unmasked, or have really high activity on 
tracker bug and good reasoning (mask for ruby-1.9 and so on).

* Masks for removal...
Nothing to say here, they are done quite well right now, and treecleaners kill 
them when they got time :]

* Masks for security...
These are the only one masks that are permanent (probably none will fix the 
nethack,...). They should be maybe even kept on the bottom of the package.mask 
file all together and separated with some comment, so they are always easy to 
spot from first look on that file.

Any more ideas/suggestions to the above?

Cheers

--------
Tomáš Chvátal
Gentoo Linux Developer [KDE/Overlays/QA/Sunrise/X11]
E-Mail          : scarabeus@gentoo.org
GnuPG FP        : 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587
GnuPG ID        : 03414587

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] QA: package.mask policies

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

Hi all,

I'm not QA, but I'll go ahead and add my comments to this also.

On Sat, Nov 07, 2009 at 06:24:10PM +0100, Tom???? Chv??tal wrote:
> * Masking beta...
> This masks are good if the software release is KNOWN to break previous 
> behaviour or degrade user experience. Otherwise the software should not be 
> masked (its TESTING for purpose, not stable).
 
 Agreed.  If it works and does not cause issues for users or degrade
 their experience, it should be in ~arch, not in p.mask.

> Also the maintainer should watch if the testing branch is still relevant (why 
> on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 is 
> stable ;]) and remove the branch+mask when needed.
 
Definitely.  If a newer version of a package is stable, or in
~arch for that matter, why do we still have the old version in the tree
and masked while the newer version is unmasked?

> * Masking live...
> Heck no. This is not proper usage. Just use keywords mask. KEYWORDS="". 
> Problem solved and the package.mask is smaller. (Note, in overlays do what 
> ever you want, since it does not polute the main mask from g-x86).
 
 True.  If we mask live ebuilds with KEYWORDS="", there isn't a reason
 to put them in p.mask that I can think of.

> * Masking stable releases...
> Here i found most interesting stuff around (for example mask for testing from 
> 2006, yeah not ~ material after 3 years?! :P)
> There should be policy defined that you can add the new release under p.mask if 
> you see it fit, but the mask can stay only for 6 months (less/more, 
> suggestions?) and then it must be unmasked, or have really high activity on 
> tracker bug and good reasoning (mask for ruby-1.9 and so on).
 
Off the top of my head, I think this falls under category 1 above as
well.  If a new release of a package and everything that uses the new
package can be installed in a way that does not degrade the user's
experience if they want to use the older release, it doesn't need to be
in p.mask.  In general, I don't think a new release of a package should
be added to p.mask unless it fits category 1 above.

Things that have been "masked for testing" for years need to have
a decision made about them -- keep them in the tree and unmask them or
remove them.

-- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: QA: package.mask policies

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

Hi,

William Hubbs <williamh@gentoo.org>:
> > * Masking live...
> > Heck no. This is not proper usage. Just use keywords mask.
> > KEYWORDS="". Problem solved and the package.mask is smaller. (Note,
> > in overlays do what ever you want, since it does not polute the
> > main mask from g-x86).
>  
>  True.  If we mask live ebuilds with KEYWORDS="", there isn't a reason
>  to put them in p.mask that I can think of.

 Many users use "**" in their p.keywords file and get a live ebuild
then.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: QA: package.mask policies

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Sat, Nov 07, 2009 at 07:33:12PM +0100, Christian Faulhammer wrote:
> Hi,
> 
> William Hubbs <williamh@gentoo.org>:
> > > * Masking live...
> > > Heck no. This is not proper usage. Just use keywords mask.
> > > KEYWORDS="". Problem solved and the package.mask is smaller. (Note,
> > > in overlays do what ever you want, since it does not polute the
> > > main mask from g-x86).
> >  
> >  True.  If we mask live ebuilds with KEYWORDS="", there isn't a reason
> >  to put them in p.mask that I can think of.
> 
>  Many users use "**" in their p.keywords file and get a live ebuild
> then.
 
 If a user runs ~arch even for one package, they should be able to
 recover if things break temporarily.  So, if they are putting ** in
 their package.keywords for packages, that is another level past ~arch
 to me.  They should definitely be able to recover in that situation.

-- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: QA: package.mask policies

[Duncan]

Christian Faulhammer posted on Sat, 07 Nov 2009 19:33:12 +0100 as
excerpted:

> William Hubbs <williamh@gentoo.org>:
>> > * Masking live...
>> > Heck no. This is not proper usage. Just use keywords mask.
>> > KEYWORDS="". Problem solved and the package.mask is smaller. (Note,
>> > in overlays do what ever you want, since it does not polute the main
>> > mask from g-x86).
>>  
>>  True.  If we mask live ebuilds with KEYWORDS="", there isn't a reason
>>  to put them in p.mask that I can think of.
> 
>  Many users use "**" in their p.keywords file and get a live ebuild
> then.

There's two different ways of seeing that.

1) Users using ** in their package.keywords file should know enough about 
what they're doing to use their own package.mask, as well.  If they're 
using ** in the keywords file, they're /saying/ they're reading to handle 
such things, after all, why shouldn't we let them?

2) That won't necessarily stop the bugs from rolling in.  Some devs may 
get tired of live pkg bugs and package.mask it, thus putting up a double-
barrier to the live ebuild.  If users jump BOTH barriers and fall over 
the ledge, well... maybe they /need/ that Darwin Award! =:^]

Thus I can see either way.  If a dev's sick of dealing with live package 
bugs, maybe a package.mask will keep a few more folks from jumping over 
that ledge and filing them.

-- 
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

Re: [gentoo-dev] Re: QA: package.mask policies

[Nirbheek Chauhan]

On Sun, Nov 8, 2009 at 12:33 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> 2) That won't necessarily stop the bugs from rolling in.  Some devs may
> get tired of live pkg bugs and package.mask it, thus putting up a double-
> barrier to the live ebuild.  If users jump BOTH barriers and fall over
> the ledge, well... maybe they /need/ that Darwin Award! =:^]
>

We had something interesting happen with policykit. It was masked for
a very long time, and so all users of policykit had
"sys-auth/policykit" in p.unmask. Then it was unmasked, but of course
who bothers cleaning up their local configuration as long as it works?

Months later, policykit-0.92 was added (masked) which was ABI, API,
UI, everything incompatible. Naturally portage on said users' boxes
was very happy to see such an update on the system and it very
promptly upgraded policykit.

And of course it completely hosed everything on top of X.

We received bug reports for this a *long* time after adding it. After
getting sick of duping, and since the new ebuild was broken in a few
ways too (and we had decided to rename policykit-0.92 it to
sys-auth/polkit), we finally decided to remove it.

Lesson to be learnt: users are morons with short attention spans[1].
But we cannot ignore that fact.


1. Of course, we ourselves come under the definition of "users" too.. ;)

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

[gentoo-dev] Re: QA: package.mask policies

[Duncan]

Nirbheek Chauhan posted on Sun, 08 Nov 2009 05:38:56 +0530 as excerpted:

> We had something interesting happen with policykit. It was masked for a
> very long time, and so all users of policykit had "sys-auth/policykit"
> in p.unmask. Then it was unmasked, but of course who bothers cleaning up
> their local configuration as long as it works?
> 
> Months later, policykit-0.92 was added (masked) which was ABI, API, UI,
> everything incompatible.

> And of course it completely hosed everything on top of X.

> Lesson to be learnt: users are morons with short attention spans[1].

> 1. Of course, we ourselves come under the definition of "users" too.. ;)

Ouch!  I've had something like that bite me (user-side) too, when I 
wondered why my package.mask entry wasn't being honored... I had a 
package.unmask entry too!

In theory that's what those stupid version string thingys are for, but 
it's soooo much easier just to forget one! =:^[

Maybe something about this should go in the handbook -- a suggestion that 
if one is going to use a package.unmask entry, that they copy the 
package.mask entry over, thus at least letting the devs minimize the 
version spread damage with their package.mask entries.  That's what I've 
started doing, and it works surprisingly well, as I have right there the 
comment on why it was masked (and add a comment on why I'm unmasking, 
when I think I might wonder, later), and it's the exact same versions the 
devs masked in the first place, so I don't have to worry so much about 
unintended version spread -- at least as long as the devs doing the 
masking worried about it then. =:^)

What do you devs think?  Would that be a practical hint for the 
handbook?  Would it be helpful in allowing /you/ to control the version 
spread of the unmask, by consequence of your control of the version 
spread on the mask in the first place?

-- 
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

Re: [gentoo-dev] Re: QA: package.mask policies

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

On Sun, Nov 8, 2009 at 1:08 PM, Nirbheek Chauhan <nirbheek@gentoo.org>wrote:

> On Sun, Nov 8, 2009 at 12:33 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> > 2) That won't necessarily stop the bugs from rolling in.  Some devs may
> > get tired of live pkg bugs and package.mask it, thus putting up a double-
> > barrier to the live ebuild.  If users jump BOTH barriers and fall over
> > the ledge, well... maybe they /need/ that Darwin Award! =:^]
> >
>
> We had something interesting happen with policykit. It was masked for
> a very long time, and so all users of policykit had
> "sys-auth/policykit" in p.unmask. Then it was unmasked, but of course
> who bothers cleaning up their local configuration as long as it works?
>
> Months later, policykit-0.92 was added (masked) which was ABI, API,
> UI, everything incompatible. Naturally portage on said users' boxes
> was very happy to see such an update on the system and it very
> promptly upgraded policykit.
>
> And of course it completely hosed everything on top of X.
>
> We received bug reports for this a *long* time after adding it. After
> getting sick of duping, and since the new ebuild was broken in a few
> ways too (and we had decided to rename policykit-0.92 it to
> sys-auth/polkit), we finally decided to remove it.
>
> Lesson to be learnt: users are morons with short attention spans[1].
> But we cannot ignore that fact.
>
>
>
In such cases users should be using version specific/version ranges for
p.keywords/p.unmask.

I don't recall seeing much literature on this practice though with regards
to standard recommendations of users and how they should use their own
p.keywords and p.unmask.

Maybe a good standard practice would be to *not* use ranged p.masks and have
explicit =version p.masks, so that users who use the commonly available
scripts that just copy from p.mask  to p.unmask don't get silently bitten as
a consequence.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 )
for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

[-- Attachment #2: Type: text/html, Size: 2622 bytes --]

Re: [gentoo-dev] QA: package.mask policies

[Peter Volkov]

В Сбт, 07/11/2009 в 18:24 +0100, Tomáš Chvátal пишет:
> * Masking beta...
> This masks are good if the software release is KNOWN to break previous 
> behaviour or degrade user experience. Otherwise the software should not be 
> masked (its TESTING for purpose, not stable).

God no! If we'll start to do this way we'll loose a way to test packages
that are supposed to go stable. It was told many times that testing
branch is for testing ebuilds, not for packages and if upstream
conciders them beta mask them. Or do you want Gentoo to have upstream
suggested _only for testers_ versions end in stable tree?

> Also the maintainer should watch if the testing branch is still relevant (why 
> on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 is 
> stable ;]) and remove the branch+mask when needed.

Yup, such things happen, but this does not mean we should stop using
package.mask for beta software.

-- 
Peter.

[gentoo-dev] Re: QA: package.mask policies

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Hi,

Duncan <1i5t5.duncan@cox.net>:
> 1) Users using ** in their package.keywords file should know enough
> about what they're doing to use their own package.mask, as well.  If
> they're using ** in the keywords file, they're /saying/ they're
> reading to handle such things, after all, why shouldn't we let them?

 They do it, because they don't know what they are doing.  Just seen it
somewhere, heard about it.  During LinuxTag the question why ** unmasks
some live ebuilds occured at least three times.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] QA: package.mask policies

[Jeroen Roovers]

On Sat, 7 Nov 2009 18:24:10 +0100
Tomáš Chvátal <scarabeus@gentoo.org> wrote:

> * Masking beta...
> This masks are good if the software release is KNOWN to break
> previous behaviour or degrade user experience. Otherwise the software
> should not be masked (its TESTING for purpose, not stable).
> Also the maintainer should watch if the testing branch is still
> relevant (why on earth we have masked 4.0.3_p20070403 version of
> screen when newer 4.3 is stable ;]) and remove the branch+mask when
> needed.

I agree with your criticism (i.e. that the mask should not be there,
especially not for "testing" as what the mask does is *prevent* testing
instead of enabling it), but must note that your version sorting
algorithm appears to be flawed: pkg-vX_pY (for patch level) is always
greater than pkg-vX.


Regards,
     jer

Re: [gentoo-dev] QA: package.mask policies

[Tomáš Chvátal]

[-- Attachment #1: Type: Text/Plain, Size: 1334 bytes --]

Dne neděle 08 Listopad 2009 17:57:10 Jeroen Roovers napsal(a):
> On Sat, 7 Nov 2009 18:24:10 +0100
> 
> Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > * Masking beta...
> > This masks are good if the software release is KNOWN to break
> > previous behaviour or degrade user experience. Otherwise the software
> > should not be masked (its TESTING for purpose, not stable).
> > Also the maintainer should watch if the testing branch is still
> > relevant (why on earth we have masked 4.0.3_p20070403 version of
> > screen when newer 4.3 is stable ;]) and remove the branch+mask when
> > needed.
> 
> I agree with your criticism (i.e. that the mask should not be there,
> especially not for "testing" as what the mask does is *prevent* testing
> instead of enabling it), but must note that your version sorting
> algorithm appears to be flawed: pkg-vX_pY (for patch level) is always
> greater than pkg-vX.
> 
> 
> Regards,
>      jer
> 
I agree that _p is newer than that.
But if we look on tag of screen-4.0.3 or its release:
 screen-4.0.2.tar.gz        27-Jan-2004 05:46  821K  
 screen-4.0.2.tar.gz.sig    27-Jan-2004 05:47   65   
 screen-4.0.3.tar.gz        07-Aug-2008 06:30  821K  
 screen-4.0.3.tar.gz.sig    07-Aug-2008 06:30   65   
You see the pattern? It is 1 year newer than it.

Tomas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: QA: package.mask policies

[Vlastimil Babka]

Duncan wrote:
> In theory that's what those stupid version string thingys are for, but 
> it's soooo much easier just to forget one! =:^[
> 
> Maybe something about this should go in the handbook -- a suggestion that 
> if one is going to use a package.unmask entry, that they copy the 
> package.mask entry over, thus at least letting the devs minimize the 
> version spread damage with their package.mask entries.  That's what I've 
> started doing, and it works surprisingly well, as I have right there the 
> comment on why it was masked (and add a comment on why I'm unmasking, 
> when I think I might wonder, later), and it's the exact same versions the 
> devs masked in the first place, so I don't have to worry so much about 
> unintended version spread -- at least as long as the devs doing the 
> masking worried about it then. =:^)
> 
> What do you devs think?  Would that be a practical hint for the 
> handbook?  Would it be helpful in allowing /you/ to control the version 
> spread of the unmask, by consequence of your control of the version 
> spread on the mask in the first place?

Hi,

handbook is one thing, but maybe portage could make it more prominent 
when it displays the packages to be merged, so that the users hopefuly 
notice?
- visibly distinguish (red color and stuff?) packages that are to be 
installed thanks to package.unmask or ** keyword
- print extra warnings about those entries in package.unmask and ** 
keywords that are not version restricted, if they contain the packages 
to be merged. This could follow the suggestion above - aside from the 
distinguished packages, below the list and above the yes/no (if --ask is 
used) there would be "Warning: the following packages have broad 
unmasks, you sure you want these versions?" and the list.

Vlastimil

[gentoo-dev] Re: QA: package.mask policies

[Duncan]

Christian Faulhammer posted on Sun, 08 Nov 2009 16:13:22 +0100 as
excerpted:

> Duncan <1i5t5.duncan@cox.net>:
>> 1) Users using ** in their package.keywords file should know enough
>> about what they're doing to use their own package.mask, as well.  If
>> they're using ** in the keywords file, they're /saying/ they're reading
>> to handle such things, after all, why shouldn't we let them?
> 
>  They do it, because they don't know what they are doing.  Just seen it
> somewhere, heard about it.  During LinuxTag the question why ** unmasks
> some live ebuilds occured at least three times.

Real user question numbers like that are useful to know.  Thanks.  Sure 
beats general hand-wavy arguments (like mine too, was). =:^)

-- 
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

Re: [gentoo-dev] QA: package.mask policies

[Jeroen Roovers]

On Sun, 8 Nov 2009 18:20:00 +0100
Tomáš Chvátal <scarabeus@gentoo.org> wrote:

> But if we look on tag of screen-4.0.3 or its release:
>  screen-4.0.2.tar.gz        27-Jan-2004 05:46  821K  
>  screen-4.0.2.tar.gz.sig    27-Jan-2004 05:47   65   
>  screen-4.0.3.tar.gz        07-Aug-2008 06:30  821K  
>  screen-4.0.3.tar.gz.sig    07-Aug-2008 06:30   65   
> You see the pattern? It is 1 year newer than it.

Correct. The snapshot should have been named _pre20070403.


Regards,
     jer

[gentoo-dev] Re: QA: package.mask policies

[Torsten Veller]

> Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > But if we look on tag of screen-4.0.3 or its release:
> >  screen-4.0.3.tar.gz        07-Aug-2008 06:30  821K  
> >  screen-4.0.3.tar.gz.sig    07-Aug-2008 06:30   65   

*screen-4.0.3 (25 Oct 2006)

Part of the famous "Software from the future" series.
Proudly presented by your Gentoo time travel agency.

Re: [gentoo-dev] Re: QA: package.mask policies

[Jeroen Roovers]

On Wed, 11 Nov 2009 18:11:37 +0100
Torsten Veller <ml-en@veller.net> wrote:

> > Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > > But if we look on tag of screen-4.0.3 or its release:
> > >  screen-4.0.3.tar.gz        07-Aug-2008 06:30  821K  
> > >  screen-4.0.3.tar.gz.sig    07-Aug-2008 06:30   65   
> 
> *screen-4.0.3 (25 Oct 2006)
> 
> Part of the famous "Software from the future" series.
> Proudly presented by your Gentoo time travel agency.

Yes, corrected again. The original came out in 2006, whatever the
timestamp on the site says. The _p* was a CVS snapshot that was added
to the tree years later.


I'll get me coat,
     jer