| 1 |
On Tue, 20 Sep 2011 10:48:37 -0700 |
| 2 |
Alec Warner <antarus@g.o> wrote: |
| 3 |
|
| 4 |
> On Tue, Sep 20, 2011 at 10:14 AM, Rich Freeman <rich0@g.o> |
| 5 |
> wrote: |
| 6 |
> > On Sep 20, 2011 1:05 PM, "Patrick Lauer" <patrick@g.o> wrote: |
| 7 |
> >> Good idea, but won't work retroactively out of the box. So you'd |
| 8 |
> >> need a helper script to figure out your current state (using |
| 9 |
> >> portage version and tree snapshot maybe), then prepare the |
| 10 |
> >> environment to upgrade (and how do you handle the "common" case of |
| 11 |
> >> python 2.5 only which doesn't allow newest portage anyway?) |
| 12 |
> >> |
| 13 |
> > |
| 14 |
> > Does it really need to be automated? Why not just have a big howto |
| 15 |
> > that we append to whenever we break @system upgrades? The top |
| 16 |
> > would have a table telling you where to start based on portage |
| 17 |
> > version or whatever. |
| 18 |
> > |
| 19 |
> > The howto would contain links to portage and bindist snapshots |
| 20 |
> > (just what you need to upgrade - maybe binary pkgs, maybe not). |
| 21 |
> > Then it would have a list of steps to follow. |
| 22 |
> > |
| 23 |
> > If you are three years out of date it would be a long journey, but |
| 24 |
> > it should work. I don't think we need to make it a trivial upgrade, |
| 25 |
> > just a workable one. |
| 26 |
> |
| 27 |
> Why should we put effort into supporting people running a system based |
| 28 |
> off of a three year old tree? |
| 29 |
|
| 30 |
Probably because we don't want to get the 'immature, non-caring, |
| 31 |
non-upgradeable' distro sticker. |
| 32 |
|
| 33 |
-- |
| 34 |
Best regards, |
| 35 |
Michał Górny |
Archives