Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 17:49:21
Message-Id: CAAr7Pr_2PDXP3o+w+Ui2dfA1sq9OAcF2usbqWYBAzvbA9GRezQ@mail.gmail.com
In Reply to: Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Rich Freeman
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?
> > And as far as extracting stage3s go - I've done it before in a pinch, but I > usually pick and choose individual files to keep it under control... > > Rich

Replies