Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Date: Wed, 08 Jun 2011 12:56:37
In Reply to: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild by Duncan <>
On Wed, Jun 8, 2011 at 7:17 AM, Duncan <1i5t5.duncan@×××.net> 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