On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.dun...@cox.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. 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
