[gentoo-user] What happens with masked packages?

[gentoo-user] What happens with masked packages?

[Thierry de Coulon]

Hello,

I'm running an amd64 Gentoo (but this is not a specific amd64 question) and 
have installed a few ~amd64 masked packages - and some work amzingly well.

So I googled for information as to where I might report success, so that they 
might be unmasked, but didn't find that info.

Where - and how - should I report masked packages that work?

Thierry

-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Dave Nebinger]

Thierry de Coulon wrote:
> Where - and how - should I report masked packages that work?

You don't need to report success.  There are teams of folks who 'bless' 
the packages into unmasked status when they feel they are ready.

Your lack of reporting a bug is an indication that there is nothing to 
block the package from being promoted.


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Thierry de Coulon]

On Wednesday 22 February 2006 21.02, Dave Nebinger wrote:
> Thierry de Coulon wrote:
> > Where - and how - should I report masked packages that work?
>
> You don't need to report success.  There are teams of folks who 'bless'
> the packages into unmasked status when they feel they are ready.
>
> Your lack of reporting a bug is an indication that there is nothing to
> block the package from being promoted.

Thanks. Does not seem to me to be the best solution, though: if a package is 
masked, many users won't install it, so what's the absence of bug report 
indicating?

In my case, the funny thing is: DVDRIP is not masked and does not work. 
Acidrip is masked and works like a charm.

Let's hope that the blessing folks find out.

Thierry

-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Rafael Bugajewski]

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

Thierry de Coulon wrote:

> Thanks. Does not seem to me to be the best solution, though: if a package
> is masked, many users won't install it, so what's the absence of bug report
> indicating?

You can also file a bug report that a package which you thing is stable is 
still masked. In this case a developer should examine the requested package a 
little bit deeper.

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

Re: [gentoo-user] What happens with masked packages?

[Boyd Stephen Smith Jr.]

On Wednesday 22 February 2006 14:38, Thierry de Coulon 
<tcoulon@decoulon.ch> wrote about 'Re: [gentoo-user] What happens with 
masked packages?':
> Thanks. Does not seem to me to be the best solution, though: if a
> package is masked, many users won't install it, so what's the absence of
> bug report indicating?

I hate how emerge / portage calls a missing keyword "masked".  It's really 
not the same thing as being in package.mask (so called "hard-masked").  In 
package.mask there is something decidedly broken, be it compatibility or 
otherwise.  But, there's often nothing wrong with testing besides being 
new.

~ARCH is testing, ARCH is stable.  It's like debian's 
stable/testing/unstable braches, but more fluid.  On gentoo, packages are 
generally moved from testing to stable individually, with batch moves 
reserved for suites (like KDE or Gnome) or packages with migration issues.

We have a number of users just on this mailing list that run testing 
systems all day long.  We encounter more bugs than stable users, but 
that's alright because we /want/ to test things, and have no fear of 
submitting a bug.  Now, if you want to fire off automated 'emerge -u 
world's every night, I'd suggest staying away from testing.

So far, the system has mostly worked.  I *would* like to see some changes, 
but mainly due to the fact that ~ARCH and package.mask are used for two 
purposes right now.  See <rant> below.

> In my case, the funny thing is: DVDRIP is not masked and does not work.
> Acidrip is masked and works like a charm.

Is the DVD:Rip ebuild doing something incorrectly, or is it just a poor 
package from upstream?  In the former case, please file a bug at 
bugs.gentoo.org.  In the latter, a bug can be filed, but it's more likely 
to get attention in upstream rather than at bugs.gentoo.org.

I'm not sure /exactly/ what you want from your ripping program, but I'd 
check out ANDREW (ANDREW's Not a DVD Ripping and Encoding Wizard) from the 
FSF.  Sooner or later I'm gonna write an ebuild for that sucka.

(Only my rant and .sig follow, so no need to scroll if you don't want my 
opinion.)

<rant>
Right now, we see package.mask, -*, and sometimes even ~ARCH being used to 
indicate instability from upstream.  For example, the gcc-4.1 ebuilds work 
perfectly, yet are marked -*.  As another example, there was a bit of time 
when the KDE 3.5_beta2 ebuilds worked fine (and were ~ARCH) but they were 
package.mask'ed.

>From what I understand this is incorrect.  package.mask, -*, and the ~ARCH 
(and occasionally, -ARCH) keywords are supposed to indicate the /ebuild/'s 
stability, not the upstream stability.

The problem is, we can't simply drop the practice of package.mask or -*'ing 
things like gcc-4.1 or beta versions of a DE that a good number of gentoo 
users work with everyday.  Too many systems would break if such ebuilds 
were marked STABLE with no indication that *you are installing software 
that might not work*.

What's really needed is a separate field indicating upstream 
classification, something similar to ACCEPT_KEYWORDS but indicating not 
the stability / behavior of the ebuild, but of the package from upstream.  
This would help both users (they can choose the test ebuilds, upstream, or 
both) and developers (they don't have to ever think "Was upstream broken 
or was the ebuild?" when they see a *-).  We could also do away with the 
perpetually masked cvs / -9999 versions.

It would be something like ACCEPT_UPSTREAM="BETA" in make.conf where you 
might also have HEAD, SNAPSHOT, ALPHA, RELEASE_CANDIDATE, RELEASE, 
BUG_FIX, SECURITY_FIX instead of BETA; Also there would either be special 
logic for HEAD or an additional flag in the ebuild for "always upgrade, 
even to same version", but I suppose that's a different matter.

Of course, this would require significant work, and may not even be 
something the gentoo developers would be interested in. (The existing 
system seems to work OK, even if it's not ideal.)  But, that's my two 
cents, hopefully I won't feel the need to bore the entire mailing list 
with this again for a while.  (Or maybe I'll get off my digital butt and 
learn enough about portage to fix it myself, or at least file a GLEP)
</rant>

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Dave Nebinger]

Boyd Stephen Smith Jr. wrote:
> 
> I hate how emerge / portage calls a missing keyword "masked".  It's really 
> not the same thing as being in package.mask (so called "hard-masked").
[snip]
> Right now, we see package.mask, -*, and sometimes even ~ARCH being used to 
> indicate instability from upstream.  For example, the gcc-4.1 ebuilds work 
> perfectly, yet are marked -*.  As another example, there was a bit of time 
> when the KDE 3.5_beta2 ebuilds worked fine (and were ~ARCH) but they were 
> package.mask'ed.

Unfortunately we are in such a state that you don't really know if a 
soft-masked package is soft-masked because the ebuild is unstable or 
whether the package itself is as yet considered unstable; I don't think 
the soft-masking is used in a consistent way even though the gentoo devs 
  might believe it is.

With hard-masked packages it's pretty clear that you shouldn't use them 
unless you *really* know what you're doing.

But with soft-masked packages it's not as clear.  Even if it were the 
case that soft-masking indicates only ebuild instability, the ebuild 
controls how the package is compiled, installed, configured...  A bad 
ebuild could really mess up your system even if the package itself has 
no problems.

The handbook clearly suggests that you should avoid even soft-masked 
packages for production systems, although we would all be able to say 
where we've used a soft-masked package with no issues.

Recently there was a thread going on about a user with a soft-masked 
glibc and a problem with "mdns off" in /etc/host.conf; glibc is such a 
critical system component, imagine what you'd need to do if the 
soft-masked glibc resulted in a corrupt library, the core library that 
all of your system components use in one fashion or another.  No boot, 
no shell, no command execution, no remote access to fix, etc.  You're 
left booting from a recovery disk to try to either restore from your 
latest backup (if you're making backups) or rebuilding components trying 
to get the system back to a workable state.

To that end, you should consider the consequences of using those 
soft-masked packages and whether you're willing to deal with them in the 
face of failures.


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Thierry de Coulon]

On Wednesday 22 February 2006 23.12, Boyd Stephen Smith Jr. wrote:

> > In my case, the funny thing is: DVDRIP is not masked and does not work.
> > Acidrip is masked and works like a charm.
>
> Is the DVD:Rip ebuild doing something incorrectly, or is it just a poor
> package from upstream?  In the former case, please file a bug at
> bugs.gentoo.org.  In the latter, a bug can be filed, but it's more likely
> to get attention in upstream rather than at bugs.gentoo.org.

I had to emerge with -gnome because of a compile problem with gnome-print. Now 
I can start dvdrip but it remains stuck at scanning the transcode codecs...

I had no time yet to investigate further. I'll take a look at ANDREW.

Thierry

-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Boyd Stephen Smith Jr.]

On Wednesday 22 February 2006 16:53, Thierry de Coulon 
<tcoulon@decoulon.ch> wrote about 'Re: [gentoo-user] What happens with 
masked packages?':
> On Wednesday 22 February 2006 23.12, Boyd Stephen Smith Jr. wrote:
> > > In my case, the funny thing is: DVDRIP is not masked and does not
> > > work. Acidrip is masked and works like a charm.
> >
> > Is the DVD:Rip ebuild doing something incorrectly, or is it just a
> > poor package from upstream?  In the former case, please file a bug at
> > bugs.gentoo.org.  In the latter, a bug can be filed, but it's more
> > likely to get attention in upstream rather than at bugs.gentoo.org.
>
> I had to emerge with -gnome because of a compile problem with
> gnome-print. Now I can start dvdrip but it remains stuck at scanning the
> transcode codecs...

Yeah, if the compile fails that's a gentoo bug, so I'll send you off to 
bugs.gentoo.org.  (You can also stick around and we /might/ be able to 
help.)  It's always a bug if a stable ebuild doesn't install properly 
(unless there's an appropriate error message from portage that tells you 
what you did wrong, or if some testing package is interferring.)

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Ciaran McCreesh]

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

On Wed, 22 Feb 2006 16:12:33 -0600 "Boyd Stephen Smith Jr."
<bss03@volumehost.com> wrote:
| From what I understand this is incorrect.  package.mask, -*, and the
| ~ARCH (and occasionally, -ARCH) keywords are supposed to indicate
| the /ebuild/'s stability, not the upstream stability.

Not exactly.

Top level package.mask means there's something wrong with the upstream
package. Often this is because it's a beta release. It can also be used
for major ebuild changes.

Profile package.mask means a package that's usually OK on a particular
architecture has to be masked on particular profiles. The canonical
example is gcc on archs where 32/64 bit is handled via subprofiles.

~arch means a package is a candidate for going into arch after further
testing, if said testing does not turn up new bugs. This means that
both the ebuild *and* the package should be likely to be stable.

No keyword means it's unknown whether a package will work on a
particular arch, because no-one has tested it.

-arch means a package will not work on a particular arch.

-* means the package is in some way architecture or hardware
independent (e.g. a binary only package), and so will only run on archs
that are explicitly listed.

Any package setting KEYWORDS="-*" and nothing else is abusing -*, and
will flag a warning on the QA checkers.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-user] What happens with masked packages?

[Boyd Stephen Smith Jr.]

First of all, thanks for the reply and clarification.  It's always good to 
hear from an actual developer when I start ranting.  [I know I could 
always go pick a fight on gentoo-dev, but I'll reserve that for when I've 
got a justifiable beef, and not just a half-baked rant. ;)]

On Friday 24 February 2006 11:31, Ciaran McCreesh <ciaranm@gentoo.org> 
wrote about 'Re: [gentoo-user] What happens with masked packages?':
> Top level package.mask means there's something wrong with the upstream
> package. Often this is because it's a beta release. It can also be used
> for major ebuild changes.

Okay, that's clearer, though I still wish "beta" was more cleanly separated 
from "broken" -- While betas generally are broken to some degree, they are 
purposely put out there so users will file the bugs upstream.

While I suppose the comments in package.mask do provide a method for 
determining when it's "safe" to unmask a beta, it's difficult to 
automatically handle betas.  Under my system you just set 
ACCEPT_UPSTREAM="BETA" and you get beta packages without the broken ones, 
automatically.

> ~arch means a package is a candidate for going into arch after further
> testing, if said testing does not turn up new bugs. This means that
> both the ebuild *and* the package should be likely to be stable.

So, betas shouldn't ever be ~arch?  Or is your definition of stable broad 
enough to include betas?

> -* means the package is in some way architecture or hardware
> independent (e.g. a binary only package), and so will only run on archs
> that are explicitly listed.

So, I guess glibc-2.3.6-r3.ebuild is using -* incorrectly?

> Any package setting KEYWORDS="-*" and nothing else is abusing -*, and
> will flag a warning on the QA checkers.

You mean like gcc-4.1.0_pre20060219.ebuild?

Sorry if I come off too critically [1].  I do see an unclean separation of 
upstream-stable vs. ebuild-stable in the portage system and I'd like to 
see it fixed, but everyday I appreciate how much work goes in to 
maintaining the portage tree and improving the gentoo experience.

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy

[1] Also, sorry I'm just a squeaky wheel instead of actively trying to fix 
the problem, I know there are more constructive things to do (GLEP, 
experimental portage backages, etc.) besides rant on the user list.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Ciaran McCreesh]

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

On Fri, 24 Feb 2006 14:57:43 -0600 "Boyd Stephen Smith Jr."
<bss03@volumehost.com> wrote:
| > ~arch means a package is a candidate for going into arch after
| > further testing, if said testing does not turn up new bugs. This
| > means that both the ebuild *and* the package should be likely to be
| > stable.
| 
| So, betas shouldn't ever be ~arch?  Or is your definition of stable
| broad enough to include betas?

Entirely dependent on the upstream. I've had Vim beta releases in
~arch, for example, because I'm confident in upstream's ability to do
beta releases without screwing up.

| > -* means the package is in some way architecture or hardware
| > independent (e.g. a binary only package), and so will only run on
| > archs that are explicitly listed.
| 
| So, I guess glibc-2.3.6-r3.ebuild is using -* incorrectly?

Probably.

| > Any package setting KEYWORDS="-*" and nothing else is abusing -*,
| > and will flag a warning on the QA checkers.
| 
| You mean like gcc-4.1.0_pre20060219.ebuild?

Yyyyup.

The -* abuse is one of the many things on QA's list of "stuff we want
to get fixed". However, it's considered extremely low priority on
existing packages.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-user] What happens with masked packages?

[Boyd Stephen Smith Jr.]

On Saturday 25 February 2006 12:57, Ciaran McCreesh <ciaranm@gentoo.org> 
wrote about 'Re: [gentoo-user] What happens with masked packages?':
> On Fri, 24 Feb 2006 14:57:43 -0600 "Boyd Stephen Smith Jr."
>
> <bss03@volumehost.com> wrote:
> | > ~arch means a package is a candidate for going into arch after
> | > further testing, if said testing does not turn up new bugs. This
> | > means that both the ebuild *and* the package should be likely to be
> | > stable.
> |
> | So, betas shouldn't ever be ~arch?  Or is your definition of stable
> | broad enough to include betas?
>
> Entirely dependent on the upstream. I've had Vim beta releases in
> ~arch, for example, because I'm confident in upstream's ability to do
> beta releases without screwing up.

So, it's based on the collective opinion of the gentoo developers?  
Wouldn't it be better to put that in the hands of the gentoo user?

> The -* abuse is one of the many things on QA's list of "stuff we want
> to get fixed". However, it's considered extremely low priority on
> existing packages.

As it should be, since there are well-known user work-arounds.

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Mariusz Pękala]

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

On 2006-02-25 13:34:28 -0600 (Sat, Feb), Boyd Stephen Smith Jr. wrote:
> > > So, betas shouldn't ever be ~arch?  Or is your definition of stable
> > > broad enough to include betas?
> >
> > Entirely dependent on the upstream. I've had Vim beta releases in
> > ~arch, for example, because I'm confident in upstream's ability to do
> > beta releases without screwing up.
> 
> So, it's based on the collective opinion of the gentoo developers?  
> Wouldn't it be better to put that in the hands of the gentoo user?

IMHO it already is. It's called PORTAGE_OVERLAY.

-- 
No virus found in this outgoing message.
Checked by "grep -i virus $MESSAGE"
Trust me.

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

Re: [gentoo-user] What happens with masked packages?

[Boyd Stephen Smith Jr.]

On Saturday 25 February 2006 17:47, Mariusz Pękala <skoot@qi.pl> wrote 
about 'Re: [gentoo-user] What happens with masked packages?':
> On 2006-02-25 13:34:28 -0600 (Sat, Feb), Boyd Stephen Smith Jr. wrote:
> > > > So, betas shouldn't ever be ~arch?  Or is your definition of
> > > > stable broad enough to include betas?
> > >
> > > Entirely dependent on the upstream. I've had Vim beta releases in
> > > ~arch, for example, because I'm confident in upstream's ability to
> > > do beta releases without screwing up.
> >
> > So, it's based on the collective opinion of the gentoo developers?
> > Wouldn't it be better to put that in the hands of the gentoo user?
>
> IMHO it already is. It's called PORTAGE_OVERLAY.

Again, hard to do automatically.  Wheras, if I could just set 
ACCEPT_UPSTREAM="BETA" I'd get all the betas.  Or I could use 
package.upstream and but in "kde-extra/kaffeine ALPHA" and get anything 
assigned more than a snapshot number for that package.  (Instead of 
manually checking after each sync to see if there's a new, masked 
version.)

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.net
ICQ: 514984 YM/AIM: DaTwinkDaddy

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Mariusz Pękala]

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

On 2006-02-25 23:16:36 -0600 (Sat, Feb), Boyd Stephen Smith Jr. wrote:
> > > So, it's based on the collective opinion of the gentoo developers?
> > > Wouldn't it be better to put that in the hands of the gentoo user?
> >
> > IMHO it already is. It's called PORTAGE_OVERLAY.
> 
> Again, hard to do automatically.  Wheras, if I could just set 
> ACCEPT_UPSTREAM="BETA" I'd get all the betas.  Or I could use 
> package.upstream and but in "kde-extra/kaffeine ALPHA" and get anything 
> assigned more than a snapshot number for that package.  (Instead of 
> manually checking after each sync to see if there's a new, masked 
> version.)

In 'man 5 ebuild' I see:

  Atom Versions
    It  is  nice  to be more specific and say that only certain versions of atoms
    are acceptable.  Note that versions must be combined with a prefix (see below).
    Hence you may add a version number as a postfix to the base:

    sys-apps/sed-4.0.5
    sys-libs/zlib-1.1.4-r1
    net-misc/dhcp-3.0_p2

    Versions  are normally made up of two or three numbers separated by periods,
    such as 1.2 or 4.5.2.  This string may be followed by a character such as 1.2a
    or 4.5.2z.  Note that this letter  is  not  meant  to indicate  alpha,  beta,
    etc...  status.   For that, use the optional suffix; either _alpha, _beta, _pre
    (pre-release), _rc (release candidate), or _p (patch).  This means for the 3rd
    pre-release of a package, you would use something like 1.2_pre3.

I suppose that you could prepare a script that builds your
/etc/portage files to unmask packages with _beta versions,
or with any other criteria contained in ebuild.

-- 
No virus found in this outgoing message.
Checked by "grep -i virus $MESSAGE"
Trust me.

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

Re: [gentoo-user] What happens with masked packages?

[Bo Andresen]

On Sunday 26 February 2006 06:16, Boyd Stephen Smith Jr. wrote:
> Again, hard to do automatically.  Wheras, if I could just set
> ACCEPT_UPSTREAM="BETA" I'd get all the betas.  Or I could use
> package.upstream and but in "kde-extra/kaffeine ALPHA" and get anything
> assigned more than a snapshot number for that package.  (Instead of
> manually checking after each sync to see if there's a new, masked
> version.)

How exactly is is you want this to work. I mean for example 
gaim-2.0.0_beta2-r1 is a beta and it's very unstable (well, it crashed 
occasionally for me). In order to get it you need to put it in package.unmask 
and package.keywords. Do you want to have to put it package.upstream too? Or 
don't you want it to be masked even though it's very unstable? Should 
package.upstream override package.mask?

-- 
Bo Andresen
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Boyd Stephen Smith Jr.]

On Sunday 26 February 2006 11:06, Bo Andresen <bo.andresen@gmail.com> wrote 
about 'Re: [gentoo-user] What happens with masked packages?':
> On Sunday 26 February 2006 06:16, Boyd Stephen Smith Jr. wrote:
> > Again, hard to do automatically.  Wheras, if I could just set
> > ACCEPT_UPSTREAM="BETA" I'd get all the betas.  Or I could use
> > package.upstream and but in "kde-extra/kaffeine ALPHA" and get
> > anything assigned more than a snapshot number for that package. 
> > (Instead of manually checking after each sync to see if there's a new,
> > masked version.)
>
> How exactly is is you want this to work. 

My proposal at this point, would be for an additional restriction on 
packages based on a new UPSTREAM variable in the ebuild itself, 
ACCEPT_UPSTREAM variable in make.conf / the environment, and the 
package.upstream file in /etc/portage.

These would be directly analogous to KEYWORDS, ACCEPT_KEYWORDS, and 
package.keywords, as would its interaction with package.mask.

> I mean for example 
> gaim-2.0.0_beta2-r1 is a beta and it's very unstable (well, it crashed
> occasionally for me). In order to get it you need to put it in
> package.unmask and package.keywords.

For any specific package, I'd have to know why it's in package.mask and why 
it's ~ARCH instead of ARCH.

If something like my proposal were actually implemented, there would be 
some transitional period that you might see a _beta ebuild in package.mask 
or marked as ~ARCH simply because it's beta, but that would go away with 
new ebuilds (well, not entirely...)

Hazarding a guess for this package, I'd say it would be removed from 
package.mask but the ebuild would retain the ~ARCH instead of ARCH 
(likely, the ebuild is also unstable, but I don't know.)

> Do you want to have to put it 
> package.upstream too?

Yes, you'd have to add 'net-im/gaim BETA' to package.upstream if you wanted 
all gaim betas.  Many users would probably be better served with 
'=net-im/gaim-2* BETA'.

You could remove it from your package.unmask because it wouldn't have to be 
masked by package.unmask (the default ACCEPT_UPSTREAM would not include 
BETA).

> Or don't you want it to be masked even though it's 
> very unstable?

I would like package.mask reserved for migration issues, package suite 
issues, and ebuilds and packages that destructively interfere with other 
packages.

I'm guessing that the gaim beta doesn't have any of these issues, so it 
would not be in package.mask but would be labeled UPSTREAM="BETA".

> Should package.upstream override package.mask? 

No, it would only change your ACCEPT_UPSTREAM for certain packages, similar 
to the way package.keywords changes your ACCEPT_KEYWORDS.

At this point, I'd really like to take this theoretical discussion off the 
the general user list; I doubt many users will be interested.  I haven't 
done any coding work on this proposal or even began writing a GLEP, so 
this is all theory without any action at this point.

I'm absolutely willing and eager to discuss things further via private 
email.  My email address is in the from header, unmunged.  I just don't 
want to waste the bandwidth of users that aren't interested in my 
vapor-proposal.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[John J. Foster]

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

On Sun, Feb 26, 2006 at 02:40:31PM -0600, Boyd Stephen Smith Jr. wrote:
> At this point, I'd really like to take this theoretical discussion off the 
> the general user list; I doubt many users will be interested.  I haven't 
> done any coding work on this proposal or even began writing a GLEP, so 
> this is all theory without any action at this point.

Please don't take this off list, as I think this is quite relevant here.

festus

-- 
I contend we are both atheists, I just believe in one fewer gods than
you do. When you understand why you dismiss all the other possible gods, 
you will understand why I dismiss yours.
                                                    ...Stephen F Roberts

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

Re: [gentoo-user] What happens with masked packages?

[Bo Andresen]

On Sunday 26 February 2006 21:40, Boyd Stephen Smith Jr. wrote:
> > How exactly is is you want this to work.
>
> My proposal at this point, would be for an additional restriction on
> packages based on a new UPSTREAM variable in the ebuild itself,
> ACCEPT_UPSTREAM variable in make.conf / the environment, and the
> package.upstream file in /etc/portage.

I read your previous posts about this as that you wanted it to be easier to 
get beta versions but what you want is in fact the exact opposite - further 
restriction. Now I get it.

-- 
Bo Andresen
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Boyd Stephen Smith Jr.]

On Sunday 26 February 2006 18:15, Bo Andresen <bo.andresen@gmail.com> wrote 
about 'Re: [gentoo-user] What happens with masked packages?':
> On Sunday 26 February 2006 21:40, Boyd Stephen Smith Jr. wrote:
> > > How exactly is is you want this to work.
> >
> > My proposal at this point, would be for an additional restriction on
> > packages based on a new UPSTREAM variable in the ebuild itself,
> > ACCEPT_UPSTREAM variable in make.conf / the environment, and the
> > package.upstream file in /etc/portage.
>
> I read your previous posts about this as that you wanted it to be easier
> to get beta versions but what you want is in fact the exact opposite -
> further restriction. Now I get it.

Well, it would make it easier by moving them /out/ of package.mask and 
putting them in a classification similar to KEYWORDS.  Then, to get all 
the betas my heart desires I can simply set ACCEPT_UPSTREAM="BETA", 
instead of manually pawing through package.mask to add them all to 
package.unmask.

In particular, I update my system regularly with emerge -avtuND world.  
This won't give me any notification that betas are available but masked.  
I'd like to configure my system so that any new betas of kaffeine, 
kmplayer, ktorrent, and the nsplugins for kaffeine and kmplayer would be 
installed with having to regularly check on them myself.

I'm imaging the default provided by the base profile would be 
ACCEPT_UPSTREAM="RELEASE BUG_FIX SECURITY_FIX" so that packages with 
UPSTREAM="BETA" (or HEAD, SNAPSHOT, ALPHA, PRE_RELEASE, RELEASE_CANDIDATE, 
alia al) would not be installed.  (Until you changes your ACCEPT_UPSTREAM 
in make.conf or edit /etc/portage/package.upstream)

I'd like upstream stability more cleanly separated from ebuild stability.  
Ciaran did clarify the roles of the various keywords and the global and 
profile-provided package.masks; from my experience I couldn't see the 
degree of separation that is intended -- dismissing the few abuses that 
are still in the portage tree.  I still think my system would be better, 
but I'm biased. :)

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Zac Slade]

On Sunday 26 February 2006 18:57, Boyd Stephen Smith Jr. wrote:
> > > My proposal at this point, would be for an additional restriction on
> > > packages based on a new UPSTREAM variable in the ebuild itself,
> > > ACCEPT_UPSTREAM variable in make.conf / the environment, and the
> > > package.upstream file in /etc/portage.
Stephen and I have talked about this before.  The real fleshed out idea is 
meant to be for a user that might want to follow a package as it moves from 
alpha->beta->release.  While the overall stability of the system might be 
compromised by globally adding an ACCEPT_UPSTREAM=BETA an individual may be 
willing to make that compromise to test new applications and provide upstream 
bug reports before a package has made it to final release.

> > I read your previous posts about this as that you wanted it to be easier
> > to get beta versions but what you want is in fact the exact opposite -
> > further restriction. Now I get it.
I don't envision it as further restriction, instead it's a way to add 
seperation of ebuild/software stability.  Imagine that I have a package that 
is in early alpha state and very unstable.  However the ebuild for that 
package does not hurt the system, it's proper and conforms to portage and 
plays nicely.  Under the current system if my ebuild was added to portage it 
would be masked with package.mask.  Under the new system it would not be in 
package.mask, instead a user would have to set ACCEPT_UPSTREAM=ALPHA or set 
mypackage ALPHA in package.upstream.

This also facilitates cvs ebuilds nicely by not having to hard mask 
everything, but instead making the user choose the system's level of 
stability.  Of course the defaults would be sane, but then the user could 
override it globally or locally to each package.  This would clean 
package.mask up and make it purely for misbehaving ebuilds.

> I'm imaging the default provided by the base profile would be
> ACCEPT_UPSTREAM="RELEASE BUG_FIX SECURITY_FIX" so that packages with
> UPSTREAM="BETA" (or HEAD, SNAPSHOT, ALPHA, PRE_RELEASE, RELEASE_CANDIDATE,
> alia al) would not be installed.  (Until you changes your ACCEPT_UPSTREAM
> in make.conf or edit /etc/portage/package.upstream)

Let's take a real life example of the cloudiness of the current situation.  If 
you run ~arch right now and update your system it will pull a new kernel in 
even if that kernel is a release candidate.  The ebuild is clean and installs 
properly and is not in package.mask, however if you don't want release 
candidate kernels there isn't an easy way to do it and only allow released 
version.  Under the new system the kernel ebuilds would still be handled the 
same way (not placed into package.mask), but the user wouldn't get a release 
candidate kernel unless they say ACCEPT_UPSTREAM=RELEASE_CANDIDATE or set the 
kernel up that way in package.upstream.

Another example that sticks out in my head.  In the run up to KDE 3.5 I wanted 
to follow all the ALPHA, BETA and RC releases so I could file bug reports and 
make the final version better.  There wasn't an easy way to do this and the 
list of packages to unmask was enourmous.  Somewhere near beta2 all the 
ebuils were good, so it could be cleanly merged, but you had to go through 
the unmask dance.  Under the new system once the ebuilds were clean, they 
would move out of package.mask and any user with the appropriate 
ACCEPT_UPSTREAM/package.upstream settings could test the new KDE.

> "If there's one thing we've established over the years,
> it's that the vast majority of our users don't have the slightest
> clue what's best for them in terms of package stability."
> -- Gentoo Developer Ciaran McCreesh
I can't believe he said that!  What he might have meant is that we should 
provide sane defaults to our users so newcomers don't get hosed systems due 
to us requiring intimate knowledge of the system.  While we shouldn't make 
unsafe policies at the global level we should allow advanced users to do as 
they please.
-- 
Zac Slade
krakrjak@volumehost.net
ICQ:1415282 YM:krakrjak AIM:ttyp99
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Ciaran McCreesh]

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

On Sat, 25 Feb 2006 13:34:28 -0600 "Boyd Stephen Smith Jr."
<bss03@volumehost.com> wrote:
| > | > ~arch means a package is a candidate for going into arch after
| > | > further testing, if said testing does not turn up new bugs. This
| > | > means that both the ebuild *and* the package should be likely
| > | > to be stable.
| > |
| > | So, betas shouldn't ever be ~arch?  Or is your definition of
| > | stable broad enough to include betas?
| >
| > Entirely dependent on the upstream. I've had Vim beta releases in
| > ~arch, for example, because I'm confident in upstream's ability to
| > do beta releases without screwing up.
| 
| So, it's based on the collective opinion of the gentoo developers?  
| Wouldn't it be better to put that in the hands of the gentoo user?

Absolutely not. If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest clue
what's best for them in terms of package stability.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-user] What happens with masked packages?

[John J. Foster]

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

On Sun, Feb 26, 2006 at 04:11:08PM +0000, Ciaran McCreesh wrote:
> Absolutely not. If there's one thing we've established over the years,
> it's that the vast majority of our users don't have the slightest clue
> what's best for them in terms of package stability.
> 
Excuse me my friend, but I switched to Gentoo because of this attitude with
every other distro I've moved away from !!!

festus

-- 
I contend we are both atheists, I just believe in one fewer gods than
you do. When you understand why you dismiss all the other possible gods, 
you will understand why I dismiss yours.
                                                    ...Stephen F Roberts

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

Re: [gentoo-user] What happens with masked packages?

[Ciaran McCreesh]

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

On Sun, 26 Feb 2006 18:29:52 -0500 "John J. Foster"
<Gentoo-User@festus.150ml.com> wrote:
| On Sun, Feb 26, 2006 at 04:11:08PM +0000, Ciaran McCreesh wrote:
| > Absolutely not. If there's one thing we've established over the
| > years, it's that the vast majority of our users don't have the
| > slightest clue what's best for them in terms of package stability.
|
| Excuse me my friend, but I switched to Gentoo because of this
| attitude with every other distro I've moved away from !!!

The distro people are right. The difference between Gentoo and most
other distributions is that we make it easier for you to override our
decisions, should you feel the need.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-user] What happens with masked packages?

[John J. Foster]

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

On Mon, Feb 27, 2006 at 12:11:02AM +0000, Ciaran McCreesh wrote:
> On Sun, 26 Feb 2006 18:29:52 -0500 "John J. Foster"
> <Gentoo-User@festus.150ml.com> wrote:
> | On Sun, Feb 26, 2006 at 04:11:08PM +0000, Ciaran McCreesh wrote:
> | > Absolutely not. If there's one thing we've established over the
> | > years, it's that the vast majority of our users don't have the
> | > slightest clue what's best for them in terms of package stability.
> |
> | Excuse me my friend, but I switched to Gentoo because of this
> | attitude with every other distro I've moved away from !!!
> 
> The distro people are right. The difference between Gentoo and most
> other distributions is that we make it easier for you to override our
> decisions, should you feel the need.
> 
Ciarin,

That's a very true statement, and part of the attraction of Gentoo. But
your comment about most users (at least of this distro) not having the 
slightest clue what's best for them is totally off base, (except, perhaps, 
where I'm concerned ;-)).

\rant mode off\

festus

-- 
I contend we are both atheists, I just believe in one fewer gods than
you do. When you understand why you dismiss all the other possible gods, 
you will understand why I dismiss yours.
                                                    ...Stephen F Roberts

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

Re: [gentoo-user] What happens with masked packages?

[Ciaran McCreesh]

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

On Sun, 26 Feb 2006 20:26:54 -0500 "John J. Foster"
<Gentoo-User@festus.150ml.com> wrote:
| That's a very true statement, and part of the attraction of Gentoo.
| But your comment about most users (at least of this distro) not
| having the slightest clue what's best for them is totally off base,
| (except, perhaps, where I'm concerned ;-)).

Hah. Try doing bug wrangling for a week and you might change that
opinion.

Anyway, part of the point of using a distribution is that it spares you
from having to know what's best for you.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-user] What happens with masked packages?

[Dave Nebinger]

Ciaran McCreesh wrote:
> Anyway, part of the point of using a distribution is that it spares you
> from having to know what's best for you.

That's a little harsh, Ciaran.  I did the linux from scratch thing.  Had 
a lot of fun with it.  Enjoyed being down in the bowels of the linux 
system and the total control over what was installed.  I knew what was 
best for me, I knew what my requirements were and built the box to 
satisfy those requirements.

Then after a few weeks of tracking freshmeat daily to see what updates I 
needed to download and apply manually, I stumbled upon gentoo and have 
been a happy gentoo'er since.  I never lost sight of what was best for 
me, what my requirements were.  I merely had to alter my processes to 
incorporate the automated nature that gentoo offers (what a relief that 
was ;-)

Your statement is probably true for all of the binary distribution 
folks.  But I doubt that you'll get many from this crowd that would say 
that we want or expect the gentoo team to "know what's best for [us]."


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] What happens with masked packages?

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 12:33:46 -0500 Dave Nebinger <dnebinger@joat.com>
wrote:
| Your statement is probably true for all of the binary distribution 
| folks.  But I doubt that you'll get many from this crowd that would
| say that we want or expect the gentoo team to "know what's best for
| [us]."

What, you think that everyone here knows exactly which version of gcc,
with which patches and which corresponding binutils to use? You think
that everyone here knows exactly which versions of db they do and do
not need installed? You think that everyone here knows which kernel
headers they should be using and in what way they should be patched?

Most of our users don't have a clue about those questions. Heck, most
of our devs don't either. Figuring all that stuff out correctly is a
hell of a lot of work. One of the major reasons for using Gentoo over
LFS is that someone else has done said work for you.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-user] What happens with masked packages?

[Boyd Stephen Smith Jr.]

On Wednesday 22 February 2006 13:55, Thierry de Coulon 
<tcoulon@decoulon.ch> wrote about '[gentoo-user] What happens with masked 
packages?':
> I'm running an amd64 Gentoo (but this is not a specific amd64 question)
> and have installed a few ~amd64 masked packages - and some work amzingly
> well.

Glad to hear it.  I run entirely ~amd64 on my desktop and things work like 
a charm.

> So I googled for information as to where I might report success, so that
> they might be unmasked, but didn't find that info.

No need to report success.  If the maintainer is happy with the ebuild and 
there are no bugs filed for 30 days (or is it 90?) the package will be 
moved from testing (~arch) to stable (arch).

Remember that these keywords are (generally) for the ebuild, and doesn't 
indicate how well the product provided by upstream works.

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy
-- 
gentoo-user@gentoo.org mailing list