1 |
On Sep 20, 2011 1:05 PM, "Patrick Lauer" <patrick@g.o> wrote: |
2 |
> Good idea, but won't work retroactively out of the box. So you'd need a |
3 |
helper script to figure out your current state (using portage version and |
4 |
tree snapshot maybe), then prepare the environment to upgrade |
5 |
> (and how do you handle the "common" case of python 2.5 only which doesn't |
6 |
allow newest portage anyway?) |
7 |
> |
8 |
|
9 |
Does it really need to be automated? Why not just have a big howto that we |
10 |
append to whenever we break @system upgrades? The top would have a table |
11 |
telling you where to start based on portage version or whatever. |
12 |
|
13 |
The howto would contain links to portage and bindist snapshots (just what |
14 |
you need to upgrade - maybe binary pkgs, maybe not). Then it would have a |
15 |
list of steps to follow. |
16 |
|
17 |
If you are three years out of date it would be a long journey, but it should |
18 |
work. I don't think we need to make it a trivial upgrade, just a workable |
19 |
one. |
20 |
|
21 |
And as far as extracting stage3s go - I've done it before in a pinch, but I |
22 |
usually pick and choose individual files to keep it under control... |
23 |
|
24 |
Rich |