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: Alex Alexander <wired@g.o>
Subject: Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 10:12:51 +0300
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@...> 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
++ www.linuxized.com


Replies:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Patrick Lauer
References:
RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Alex Alexander
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Duncan
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Rich Freeman
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by thread:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Previous by date:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by date:
Re: Re: euscan proof of concept (like debian's uscan)


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.