1 |
On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote: |
2 |
> On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
3 |
> > At least an initial read suggests that you just multiplied the mirror |
4 |
> > space requirements by however many times you use this trick. I don't |
5 |
> > believe infra's going to go for that. |
6 |
> > |
7 |
> |
8 |
> Yup - and everybody needs to mirror all the BINDISTs using all those |
9 |
> older trees. I don't think this is a good option all-around. |
10 |
> |
11 |
> For most changes, honestly, I think the cleanest option is to use |
12 |
> binary packages. If you build a generic set of @system binary |
13 |
> packages then you can emerge -K them and get a bootstrappable system |
14 |
> no matter how out-of-date you are. Then you can do an emerge -uDN |
15 |
> world, or maybe just an emerge -e world. |
16 |
> |
17 |
> The only real gotcha is if portage is so old that it can't handle the |
18 |
> binary packages. However, to get around that we really just need a |
19 |
> set of step-wise binary updates for portage itself so that you can |
20 |
> sequence it up to something that can install the rest. That will work |
21 |
> as long as portage doesn't strictly need a newer dependency. If it |
22 |
> needs a newer python or something then we might need to keep a binary |
23 |
> package of that lying around - maybe statically linked so that it |
24 |
> doesn't go further than a few packages. |
25 |
> |
26 |
> Something like that really just needs a few tarballs and then an |
27 |
> up-to-date set of binary stage3 packages. The binary packages could |
28 |
> be built at the same time the stage3s are made. And, this is really |
29 |
> just a contingency plan so we don't need to mirror all that stuff - we |
30 |
> could even just make it torrent-only or something. |
31 |
|
32 |
Binary packages are useful, but you can't consider them a true fix to our |
33 |
problem. In 2011, having to do all this manual work just to keep a system |
34 |
running seems wrong. Especially when there are other solutions that would allow |
35 |
you to avoid all that. |
36 |
|
37 |
Implementing something like my proposal would save a lot of systems with |
38 |
minimal cost and make Gentoo more reliable in the public (and corporate) eye. |
39 |
|
40 |
> Or we could do what was proposed in the past and say 1 year and you're |
41 |
> done. That slows us down a little, but has zero overhead. |
42 |
|
43 |
IMHO, waiting for a year to push a serious change is unacceptable. We're a |
44 |
bleeding edge meta-distro, I'm sure we can do better ;) |
45 |
|
46 |
-- |
47 |
Alex Alexander | wired |
48 |
+ Gentoo Linux Developer |
49 |
++ www.linuxized.com |