On Tue, 20 Sep 2011 10:48:37 -0700
Alec Warner <email@example.com> wrote:
> On Tue, Sep 20, 2011 at 10:14 AM, Rich Freeman <firstname.lastname@example.org>
> > On Sep 20, 2011 1:05 PM, "Patrick Lauer" <email@example.com> 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.