FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 11-07-2009, 04:24 PM
Tomáš Chvátal
 
Default QA: package.mask policies

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
 
Old 11-07-2009, 05:03 PM
William Hubbs
 
Default QA: package.mask policies

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
 
Old 11-07-2009, 05:33 PM
Christian Faulhammer
 
Default QA: package.mask policies

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/>
 
Old 11-07-2009, 05:56 PM
William Hubbs
 
Default QA: package.mask policies

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
 
Old 11-07-2009, 06:03 PM
Duncan
 
Default QA: package.mask policies

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
 
Old 11-07-2009, 11:08 PM
Nirbheek Chauhan
 
Default QA: package.mask policies

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
 
Old 11-08-2009, 12:25 AM
Duncan
 
Default QA: package.mask policies

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
 
Old 11-08-2009, 12:26 AM
Kent Fredric
 
Default QA: package.mask policies

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
 
Old 11-08-2009, 11:41 AM
Peter Volkov
 
Default QA: package.mask policies

В Сбт, 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.
 
Old 11-08-2009, 02:13 PM
Christian Faulhammer
 
Default QA: package.mask policies

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

Thread Tools




All times are GMT. The time now is 10:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org