Gentoo Archives: gentoo-dev

From: Alex Alexander <wired@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 07:14:17
Message-Id: 20110920071251.GA82015@ion.local
In Reply to: Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Rich Freeman
On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote:
> On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.duncan@×××.net> wrote: > > At least an initial read suggests that you just multiplied the mirror > > space requirements by however many times you use this trick.  I don't > > believe infra's going to go for that. > > > > Yup - and everybody needs to mirror all the BINDISTs using all those > older trees. I don't think this is a good option all-around. > > For most changes, honestly, I think the cleanest option is to use > binary packages. If you build a generic set of @system binary > packages then you can emerge -K them and get a bootstrappable system > no matter how out-of-date you are. Then you can do an emerge -uDN > world, or maybe just an emerge -e world. > > The only real gotcha is if portage is so old that it can't handle the > binary packages. However, to get around that we really just need a > set of step-wise binary updates for portage itself so that you can > sequence it up to something that can install the rest. That will work > as long as portage doesn't strictly need a newer dependency. If it > needs a newer python or something then we might need to keep a binary > package of that lying around - maybe statically linked so that it > doesn't go further than a few packages. > > Something like that really just needs a few tarballs and then an > up-to-date set of binary stage3 packages. The binary packages could > be built at the same time the stage3s are made. And, this is really > just a contingency plan so we don't need to mirror all that stuff - we > could even just make it torrent-only or something.
Binary packages are useful, but you can't consider them a true fix to our problem. In 2011, having to do all this manual work just to keep a system running seems wrong. Especially when there are other solutions that would allow you to avoid all that. Implementing something like my proposal would save a lot of systems with minimal cost and make Gentoo more reliable in the public (and corporate) eye.
> Or we could do what was proposed in the past and say 1 year and you're > done. That slows us down a little, but has zero overhead.
IMHO, waiting for a year to push a serious change is unacceptable. We're a bleeding edge meta-distro, I'm sure we can do better ;) -- Alex Alexander | wired + Gentoo Linux Developer ++