On Tue, 20 Sep 2011 10:48:37 -0700
Alec Warner <antarus@g.o> wrote:

> On Tue, Sep 20, 2011 at 10:14 AM, Rich Freeman <rich0@g.o>
> wrote:
> > On Sep 20, 2011 1:05 PM, "Patrick Lauer" <patrick@g.o> wrote:
> >> Good idea, but won't work retroactively out of the box. So you'd
> >> need a helper script to figure out your current state (using
> >> portage version and tree snapshot maybe), then prepare the
> >> environment to upgrade (and how do you handle the "common" case of
> >> python 2.5 only which doesn't allow newest portage anyway?)
> >>
> >
> > Does it really need to be automated?  Why not just have a big howto
> > that we append to whenever we break @system upgrades?  The top
> > would have a table telling you where to start based on portage
> > version or whatever.
> >
> > The howto would contain links to portage and bindist snapshots
> > (just what you need to upgrade - maybe binary pkgs, maybe not).
> > Then it would have a list of steps to follow.
> >
> > If you are three years out of date it would be a long journey, but
> > it should work. I don't think we need to make it a trivial upgrade,
> > just a workable one.
> 
> Why should we put effort into supporting people running a system based
> off of a three year old tree?

Probably because we don't want to get the 'immature, non-caring,
non-upgradeable' distro sticker.

-- 
Best regards,
Michał Górny