1 |
On 09/20/11 09:12, Alex Alexander wrote: |
2 |
>> The only real gotcha is if portage is so old that it can't handle the |
3 |
>> binary packages. However, to get around that we really just need a |
4 |
>> set of step-wise binary updates for portage itself so that you can |
5 |
>> sequence it up to something that can install the rest. That will work |
6 |
>> as long as portage doesn't strictly need a newer dependency. If it |
7 |
>> needs a newer python or something then we might need to keep a binary |
8 |
>> package of that lying around - maybe statically linked so that it |
9 |
>> doesn't go further than a few packages. |
10 |
|
11 |
That won't work nicely. I've done enough system upgrades to have found |
12 |
funny issues along the way, for example package.mask getting in the way |
13 |
or needing a specific package merge order, which won't work if you still |
14 |
have an older glibc installed. |
15 |
|
16 |
>> Something like that really just needs a few tarballs and then an |
17 |
>> up-to-date set of binary stage3 packages. The binary packages could |
18 |
>> be built at the same time the stage3s are made. And, this is really |
19 |
>> just a contingency plan so we don't need to mirror all that stuff - we |
20 |
>> could even just make it torrent-only or something. |
21 |
> |
22 |
> Binary packages are useful, but you can't consider them a true fix to our |
23 |
> problem. In 2011, having to do all this manual work just to keep a system |
24 |
> running seems wrong. Especially when there are other solutions that would allow |
25 |
> you to avoid all that. |
26 |
|
27 |
I think we can script it away. |
28 |
We do know the last sync time and the last merge time. |
29 |
|
30 |
From this we can deduce the next snapshot we want to go to - use |
31 |
emerge-webrsync to fetch a snapshot (06-2008), emerge -eK system (this |
32 |
will break a few of the other installed packages), progress to next |
33 |
snapshot (01-2009), repeat. (I think a 6-month snapshot distance is a |
34 |
good balance between reliability and speed) |
35 |
|
36 |
(btw: you can generate most of the binpkgs you need from a stage3 |
37 |
automatically) |
38 |
|
39 |
Along the way you will have a few blockers which can mostly be figured |
40 |
out a priori (coldplug, hal, portage-python, ...) and for the most part |
41 |
scripted away too. |
42 |
(Another gotcha: kernel-udev-glibc, at some point you may have to reboot |
43 |
with a recent enough kernel just to be able to get a working glibc) |
44 |
|
45 |
Then you've upgraded @system to something from this decade and you can |
46 |
try updating the rest (which will have its own share of blockers etc) |
47 |
|
48 |
|
49 |
> Implementing something like my proposal would save a lot of systems with |
50 |
> minimal cost and make Gentoo more reliable in the public (and corporate) eye. |
51 |
> |
52 |
>> Or we could do what was proposed in the past and say 1 year and you're |
53 |
>> done. That slows us down a little, but has zero overhead. |
54 |
> |
55 |
> IMHO, waiting for a year to push a serious change is unacceptable. We're a |
56 |
> bleeding edge meta-distro, I'm sure we can do better ;) |
57 |
> |
58 |
Doesn't need a year. We have all the bits lying around, if I weren't so |
59 |
lazy I'd have started with a 2006.0 stage3 just to see how much blocker |
60 |
removal and interaction it needs. |
61 |
|
62 |
Make it into a nice script and blam, insta-update. |