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

[Patrick Lauer]

On 09/20/11 09:12, Alex Alexander wrote:
>> 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.

That won't work nicely. I've done enough system upgrades to have found
funny issues along the way, for example package.mask getting in the way
or needing a specific package merge order, which won't work if you still
have an older glibc installed.

>> 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.
>
> Binary packages are useful, but you can't consider them a true fix to our
> problem. In 2011, having to do all this manual work just to keep a system
> running seems wrong. Especially when there are other solutions that would allow
> you to avoid all that.

I think we can script it away.
We do know the last sync time and the last merge time.

From this we can deduce the next snapshot we want to go to - use
emerge-webrsync to fetch a snapshot (06-2008), emerge -eK system (this
will break a few of the other installed packages), progress to next
snapshot (01-2009), repeat. (I think a 6-month snapshot distance is a
good balance between reliability and speed)

(btw: you can generate most of the binpkgs you need from a stage3
automatically)

Along the way you will have a few blockers which can mostly be figured
out a priori (coldplug, hal, portage-python, ...) and for the most part
scripted away too.
(Another gotcha: kernel-udev-glibc, at some point you may have to reboot
with a recent enough kernel just to be able to get a working glibc)

Then you've upgraded @system to something from this decade and you can
try updating the rest (which will have its own share of blockers etc)


> Implementing something like my proposal would save a lot of systems with
> minimal cost and make Gentoo more reliable in the public (and corporate) eye.
>
>> 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.
>
> IMHO, waiting for a year to push a serious change is unacceptable. We're a
> bleeding edge meta-distro, I'm sure we can do better ;)
>
Doesn't need a year. We have all the bits lying around, if I weren't so
lazy I'd have started with a 2006.0 stage3 just to see how much blocker
removal and interaction it needs.

Make it into a nice script and blam, insta-update.