[gentoo-user] What happens with masked packages?

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 RemoveThis @gentoo.org mailing list

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.DeleteThis@gentoo.org mailing list

On Wednesday 22 February 2006 16:53, Thierry de Coulon
<tcoulon DeleteThis @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 DeleteThis @volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy
--
gentoo-user DeleteThis @gentoo.org mailing list

On Saturday 25 February 2006 12:57, Ciaran McCreesh <ciaranm.DeleteThis@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.DeleteThis@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.DeleteThis@volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy
--
gentoo-user.DeleteThis@gentoo.org mailing list

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.DeleteThis@gentoo.org mailing list

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.RemoveThis@volumehost.net
ICQ:1415282 YM:krakrjak AIM:ttyp99
--
gentoo-user.RemoveThis@gentoo.org mailing list