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.

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.

Rich