public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Boyd Stephen Smith Jr." <bss03@volumehost.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] What happens with masked packages?
Date: Sun, 26 Feb 2006 18:57:16 -0600	[thread overview]
Message-ID: <200602261857.16540.bss03@volumehost.net> (raw)
In-Reply-To: <200602270115.05500.bo.andresen@gmail.com>

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



  reply	other threads:[~2006-02-27  1:03 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.
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. [this message]
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=200602261857.16540.bss03@volumehost.net \
    --to=bss03@volumehost.net \
    --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