[gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

[Duncan]

Rich Freeman posted on Mon, 19 Sep 2011 20:46:10 -0400 as excerpted:

> For most changes, honestly, I think the cleanest option is to use binary
> packages.  If you build a generic set of @system binary packages then
> you can emerge -K them and get a bootstrappable system no matter how
> out-of-date you are.  Then you can do an emerge -uDN world, or maybe
> just an emerge -e world.

That sounds an awful lot like simply starting from a new stage-3, in a 
chroot initially, either from the existing system or from install media.  
Except the new stage-3 route bypasses the old portage/toolchain issue 
below.

> The only real gotcha is if portage is so old that it can't handle the
> binary packages.  However, to get around that we really just need a set
> of step-wise binary updates for portage itself so that you can sequence
> it up to something that can install the rest.  That will work as long as
> portage doesn't strictly need a newer dependency.  If it needs a newer
> python or something then we might need to keep a binary package of that
> lying around - maybe statically linked so that it doesn't go further
> than a few packages.

Talking about statically linked... but that's a different thread. =:^)

> Something like that really just needs a few tarballs and then an
> up-to-date set of binary stage3 packages.  The binary packages could be
> built at the same time the stage3s are made.  And, this is really just a
> contingency plan so we don't need to mirror all that stuff - we could
> even just make it torrent-only or something.
>
> Or we could do what was proposed in the past and say 1 year and you're
> done.  That slows us down a little, but has zero overhead.

Really, that's the practical limit anyway.  I've done 8-month updates on 
the 32-bit build-image chroot I use for my netbook, and it can be pretty 
hairy even at that, and even with doing regular updates on my main system 
so I've been thru most of it before by the time I deal with the netbook 
build-image.

I'd say trying to keep it at a year (but recognizing even that's going to 
be somewhat buggy and have various issues in practice, a year by policy, 
tho, and six to seven months should actually be practical) is a 
reasonable goal.  Beyond that, the new stage-3 thing should remain the 
supported upgrade path.  Gentoo isn't magic, and if a year's too short 
for someone and they can't accept the stage-3 method beyond that, they 
really should be considering whether Gentoo's the best distro for them in 
any case.

That doesn't mean we can't work on ways to shorten the incompatible turn-
around time to < 1 year, but it does provide a reasonable worst-case time-
focus window, since by policy we don't need to worry about anything 
beyond a year, anyway.  Now we're simply talking about ways to shorten 
the turn-around time to less than a year while keeping the year's 
supported upgrades policy.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman