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@××××××××××.net
ICQ:1415282 YM:krakrjak AIM:ttyp99
-- 
gentoo-user@g.o mailing list