Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Rich Freeman <rich0@g.o>
Subject: Re: Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Date: Wed, 8 Jun 2011 08:55:45 -0400
On Wed, Jun 8, 2011 at 7:17 AM, Duncan <1i5t5.duncan@...> wrote:
> He didn't say he was going to defy council, rather, that he simply
> wouldn't be removing ebuilds /at/ /all/ until either the changelog is auto-
> generated (making the case moot) or the council changes policy.
>
> That means they'll either fall to someone else to do, or will simply
> remain there, but either way, it's quite different from directly defying
> the council decision.
>

As long as all versions in the tree compile cleanly and are free from
security issues, I don't see any issue with keeping older ebuilds
around.  If anything I think that some packages are too quick to
remove ~arch versions.  I run stable but accept the odd ~arch package.
 When I do accept a ~arch package I only accept one version of it with
the goal of going stable once whatever drove me to accept ~arch gets
there.  When the ~arch package disappears I just have to re-evaluate
my new options and try again, and sometimes it feels like I never end
up in stable.  (I do realize that a few types of packages will
probably never be stable by their nature, and that is fine.)

If old versions become QA issues then we already have processes to
deal with that.  It is the duty of maintainers to deal with such
problems.

In any case, the rule is simple - if you remove an ebuild you have to
include a note in the Changelog.  That could change, or it might not,
or perhaps it will become automated, but either way it is the rule
right now.

One thing I will say is that I appreciate the civility in this thread
so far.  I think everybody on both sides of the issue realizes that
this is contentious, and I think everybody would be open to a better
solution.

Rich


References:
Re: Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-- Mike Frysinger
Re: Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-- Dale
Re: Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-- Mike Frysinger
Re: Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-- Dale
Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-- Duncan
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Next by thread:
Re: Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Previous by date:
Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Next by date:
Re: Reducing glibc's default locale.gen


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.