Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Patrick Lauer <patrick@g.o>
Subject: Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 12:43:21 +0200
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.


References:
RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Alex Alexander
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Duncan
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Rich Freeman
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Alex Alexander
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by thread:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Previous by date:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by date:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.