public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Grant Goodyear <g2boojum@gentoo.org>
To: gentoo-dev List <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'
Date: Fri, 2 Jul 2004 10:41:17 -0400	[thread overview]
Message-ID: <20040702144117.GA11463@violet.grantgoodyear.org> (raw)
In-Reply-To: <1088775875.12020.127.camel@rattus.Localdomain>

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

> A few weeks back I filed a bug (since closed, but not resolved to my
> satisfaction) on the premature removal of mm-sources and the fact that
> no stable version was left in portage.  This had the effect of breaking
> a number of perfectly working systems and leaving no alternative but to
> move to another kernel as the masked versions did not work (at the time)
> - a major hassle.

I'm probably missing something obvious, but even reading the original
bug report leaves me confused as to how a lack of stable mm-sources
ebuilds is breaking systems.  Once mm-sources is installed anything
that needs a kernel tree should build just fine.  (I don't think
we have anything in the tree that specifically requires mm-sources,
do we?)  If the problem is that somebody wants to install mm-sources but
can't because all ebuilds are arch-masked, then that's what
/etc/portage/package.keywords is for.

I don't know what the official thinking on this is, but off-the-cuff I
would tend to think that _all_ mm-sources ebuilds should really be arch
masked, since mm-sources is both bleeding-edge (by definition) and a
fast-moving target, so one expects that mm-sources ebuilds aren't likely
to be in the tree long enough to really become "stable".  Only
arch-masking release candidates seems a tad silly.  I suppose that one
might argue that they should be package masked, but since new kernels
aren't built and used automatically, I would prefer to just leave it up
to users to decide whether or not to build and use any given kernel.

> I for one would like to see a policy for this as I feel that mm-sources
> was done at the whim of a dev who was looking at his future, and wasnt
> willing to consider the user base, leaving quite a number of us
> stranded.  His justification seemed to be that mm-sources should be
> considered a dev package, so I should not have bothered - bug closed.

I agree that Greg's bug report was a tad terse, but I rather doubt that
your allegation of his motivation is correct.  

Now, as to the actual issue at hand, the common unwritten policy is that
packages generally have one (or at most a few) stable ebuild(s) and zero
or more arch-masked ebuilds.  Ideally, every mature package should have
a stable ebuild (preferably stable on every arch), but....  That said,
it's not a written policy because some packages have different needs,
and it's mostly up to the package maintainer to make those decisions.

Incidentally, we often have people suggest that ebuilds should never be
removed from the tree.  Then these sorts of problems would never arise.
If you've done a new install recently, though, you already know how long
it takes to download the initial tree, and that's with fairly active
pruning.  That's a problem that we don't have a really good solution
just yet, so for the moment we try to keep the tree pruned and we let
users who need old versions extract them from viewcvs.

Best,
g2boojum
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

  reply	other threads:[~2004-07-02 14:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-02  1:20 [gentoo-dev] Policy for retirement of old gentoo "versions" Barry Shaw
2004-07-02  2:17 ` [gentoo-dev] Policy for retirement of old gentoo 'versions' Donnie Berkholz
2004-07-02 12:48   ` Chris Gianelloni
2004-07-02 13:44     ` William Kenworthy
2004-07-02 14:41       ` Grant Goodyear [this message]
2004-07-02 15:15         ` Dylan Carlson
2004-07-02 20:29           ` Chris Gianelloni
2004-07-02 21:06             ` Dylan Carlson
2004-07-02 21:37               ` Chris Gianelloni
2004-07-03  6:34                 ` Dylan Carlson
2004-07-04 22:10                   ` Marius Mauch
2004-07-05  1:14                     ` Dylan Carlson
2004-07-04 22:16                   ` Barry Shaw
2004-07-05  1:01                     ` Dylan Carlson
2004-07-05  2:19                       ` Barry Shaw
2004-07-02 20:21       ` Chris Gianelloni

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=20040702144117.GA11463@violet.grantgoodyear.org \
    --to=g2boojum@gentoo.org \
    --cc=gentoo-dev@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