1 |
On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
> At least an initial read suggests that you just multiplied the mirror |
3 |
> space requirements by however many times you use this trick. I don't |
4 |
> believe infra's going to go for that. |
5 |
> |
6 |
|
7 |
Yup - and everybody needs to mirror all the BINDISTs using all those |
8 |
older trees. I don't think this is a good option all-around. |
9 |
|
10 |
For most changes, honestly, I think the cleanest option is to use |
11 |
binary packages. If you build a generic set of @system binary |
12 |
packages then you can emerge -K them and get a bootstrappable system |
13 |
no matter how out-of-date you are. Then you can do an emerge -uDN |
14 |
world, or maybe just an emerge -e world. |
15 |
|
16 |
The only real gotcha is if portage is so old that it can't handle the |
17 |
binary packages. However, to get around that we really just need a |
18 |
set of step-wise binary updates for portage itself so that you can |
19 |
sequence it up to something that can install the rest. That will work |
20 |
as long as portage doesn't strictly need a newer dependency. If it |
21 |
needs a newer python or something then we might need to keep a binary |
22 |
package of that lying around - maybe statically linked so that it |
23 |
doesn't go further than a few packages. |
24 |
|
25 |
Something like that really just needs a few tarballs and then an |
26 |
up-to-date set of binary stage3 packages. The binary packages could |
27 |
be built at the same time the stage3s are made. And, this is really |
28 |
just a contingency plan so we don't need to mirror all that stuff - we |
29 |
could even just make it torrent-only or something. |
30 |
|
31 |
Or we could do what was proposed in the past and say 1 year and you're |
32 |
done. That slows us down a little, but has zero overhead. |
33 |
|
34 |
Rich |