public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Boyd Stephen Smith Jr." <bss03@volumehost.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] What happens with masked packages?
Date: Wed, 22 Feb 2006 16:12:33 -0600	[thread overview]
Message-ID: <200602221612.33988.bss03@volumehost.com> (raw)
In-Reply-To: <200602222138.01006.tcoulon@decoulon.ch>

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



  parent reply	other threads:[~2006-02-22 22:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-22 19:55 [gentoo-user] What happens with masked packages? Thierry de Coulon
2006-02-22 20:02 ` Dave Nebinger
2006-02-22 20:38   ` Thierry de Coulon
2006-02-22 21:38     ` Rafael Bugajewski
2006-02-22 22:12     ` Boyd Stephen Smith Jr. [this message]
2006-02-22 22:44       ` Dave Nebinger
2006-02-22 22:53       ` Thierry de Coulon
2006-02-22 23:08         ` Boyd Stephen Smith Jr.
2006-02-24 17:31       ` Ciaran McCreesh
2006-02-24 20:57         ` Boyd Stephen Smith Jr.
2006-02-25 18:57           ` Ciaran McCreesh
2006-02-25 19:34             ` Boyd Stephen Smith Jr.
2006-02-25 23:47               ` Mariusz Pękala
2006-02-26  5:16                 ` Boyd Stephen Smith Jr.
2006-02-26 16:34                   ` Mariusz Pękala
2006-02-26 17:06                   ` Bo Andresen
2006-02-26 20:40                     ` Boyd Stephen Smith Jr.
2006-02-26 23:25                       ` John J. Foster
2006-02-27  0:15                       ` Bo Andresen
2006-02-27  0:57                         ` Boyd Stephen Smith Jr.
2006-02-27  3:44                           ` Zac Slade
2006-02-26 16:11               ` Ciaran McCreesh
2006-02-26 23:29                 ` John J. Foster
2006-02-27  0:11                   ` Ciaran McCreesh
2006-02-27  1:26                     ` John J. Foster
2006-02-27 17:17                       ` Ciaran McCreesh
2006-02-27 17:33                         ` Dave Nebinger
2006-02-27 18:51                           ` Ciaran McCreesh
2006-02-22 21:27 ` Boyd Stephen Smith Jr.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200602221612.33988.bss03@volumehost.com \
    --to=bss03@volumehost.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox