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

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

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]

EAPI in profiles and the -live version suffix are some of the improvements
many people would like to see in the tree. Unfortunately, the risk of breaking
systems with old versions of portage has been too high, holding evolution
back.

I've been thinking about a way to solve this that would be easy to implement,
without any significant compromises and one thing comes to mind:

Manipulation of the SYNC variable (i.e. rsync module),
combined with tree snapshots.

At the moment, all systems have a SYNC line similar to this:

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

My idea is simple. When incompatible changes have to be introduced to the
tree, push a new version of portage that includes support for all the new
features we want to provide.

Then, freeze the tree and clone it into a revbumped rsync module, i.e.

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"

That way the last update provided by the old tree will be the updated portage
package, which will be aware of the SYNC change.

After the user installs that update, every subsequent emerge run will print a
fat red warning telling the user that the tree has been revbumped.

It will then provide instructions on how to update the make.conf/SYNC
and a Y/N prompt to fix it itself. It could even do it automatically,
but that's debatable.

By doing this we can be sure that any user using the revbumped SYNC have
an up-to-date portage (if they cheated, well, that's their problem), allowing
us to use all the new features provided by the latest version of portage.

For the above to work, we would require at least
- support for multiple rsync modules pointing to different trees
  [also in mirrors]
- a way to freeze the current state of the tree for the current rsync module
  and push future updates to a revbumped rsync module.
- update our portage-snapshot tools to use the latest rsync module.
- other things I'm probably forgetting right now

I'm not sure how much work would be required to make our current
infrastructure support this, the infra people could shed some light on
this.

The idea is to use this system sparingly, only when we need to push big
changes that can't be supplied through an EAPI. Another example would be a
change that would break the upgrade path. By freezing the tree at the right
moment, we can be sure that the users will follow a known upgrade path
that works.

Please keep in mind that my solution isn't trying to be the best thing
possible. Instead, I'm aiming for something that would do the job and would be
implemented in a realistic timeframe.

What do you guys think?
-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Duncan]

Alex Alexander posted on Tue, 20 Sep 2011 01:14:38 +0300 as excerpted:

> At the moment, all systems have a SYNC line similar to this:
> 
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
> 
> My idea is simple. When incompatible changes have to be introduced to
> the tree, push a new version of portage that includes support for all
> the new features we want to provide.
> 
> Then, freeze the tree and clone it into a revbumped rsync module, i.e.
> 
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"
> 
> That way the last update provided by the old tree will be the updated
> portage package, which will be aware of the SYNC change.
> 
> After the user installs that update, every subsequent emerge run will
> print a fat red warning telling the user that the tree has been
> revbumped.

At least an initial read suggests that you just multiplied the mirror 
space requirements by however many times you use this trick.  I don't 
believe infra's going to go for that.

A workaround may be to eventually store the frozen tree snapshot in only 
one location, with a path change for the bump and a transparent redirect 
(does rsync handle redirects?) on the others, so those that haven't 
updated yet don't get broken.  (If rsync doesn't handle redirects, 
they'll simply get an rsync error until they investigate, and point at 
the single location for that final update before switching.)

But that's not going to work well for the initial surge, so some sort of 
transition plan will need to be implemented.  One relatively simplistic 
possibility that would at least limit the mirrors space required to 2X, 
for a limited time, would be to specify no more than one such upgrade "in 
flight" at once on the mirror network, with older ones in the single-
location archive, limiting the "in-flight" time to say two months.  
However, while that limits the space requirements to 2X and only requires 
that for a limited time, that's still a significant requirement that's 
unlikely to go over particularly well, so a rather more complex, or at 
least different, proposal seems necessary.

Please consider this in your proposal, and/or point out where I missed 
it, if indeed I did. =:^\

-- 
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

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

[Rich Freeman]

On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> At least an initial read suggests that you just multiplied the mirror
> space requirements by however many times you use this trick.  I don't
> believe infra's going to go for that.
>

Yup - and everybody needs to mirror all the BINDISTs using all those
older trees.  I don't think this is a good option all-around.

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.

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.

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.

Rich

[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

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

[Alex Alexander]

On Mon, Sep 19, 2011 at 10:53:15PM +0000, Duncan wrote:
> Alex Alexander posted on Tue, 20 Sep 2011 01:14:38 +0300 as excerpted:
> 
> > At the moment, all systems have a SYNC line similar to this:
> > 
> > SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
> > 
> > My idea is simple. When incompatible changes have to be introduced to
> > the tree, push a new version of portage that includes support for all
> > the new features we want to provide.
> > 
> > Then, freeze the tree and clone it into a revbumped rsync module, i.e.
> > 
> > SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"
> > 
> > That way the last update provided by the old tree will be the updated
> > portage package, which will be aware of the SYNC change.
> > 
> > After the user installs that update, every subsequent emerge run will
> > print a fat red warning telling the user that the tree has been
> > revbumped.
> 
> At least an initial read suggests that you just multiplied the mirror 
> space requirements by however many times you use this trick.  I don't 
> believe infra's going to go for that.
> 
> A workaround may be to eventually store the frozen tree snapshot in only 
> one location, with a path change for the bump and a transparent redirect 
> (does rsync handle redirects?) on the others, so those that haven't 
> updated yet don't get broken.  (If rsync doesn't handle redirects, 
> they'll simply get an rsync error until they investigate, and point at 
> the single location for that final update before switching.)
> 
> But that's not going to work well for the initial surge, so some sort of 
> transition plan will need to be implemented.  One relatively simplistic 
> possibility that would at least limit the mirrors space required to 2X, 
> for a limited time, would be to specify no more than one such upgrade "in 
> flight" at once on the mirror network, with older ones in the single-
> location archive, limiting the "in-flight" time to say two months.  
> However, while that limits the space requirements to 2X and only requires 
> that for a limited time, that's still a significant requirement that's 
> unlikely to go over particularly well, so a rather more complex, or at 
> least different, proposal seems necessary.
> 
> Please consider this in your proposal, and/or point out where I missed 
> it, if indeed I did. =:^\

Yes, space requirements will increase with this solution, but considering that
it will solve an important issue we're having, I'd say it is worth the
tradeoff.

Still, if space is a big issue, it could be worked around by trimming down the
frozen tree to portage and its dependencies. That can't happen in -r1 though,
since portage must be aware of what's happening so it can block any other
updates and potential downgrades resulting from the trimmed tree and overlays
before the SYNC variable is updated.

Even if we opt to keep the whole tree, we could deprecate and dump it after a year.

Usage of this feature should be as rare as possible. Having 5 revisions of the
rsync tree in a year means we're doing something wrong, but one revision per
year should be affordable (infra-wise) and would solve many problems.

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

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

[Alex Alexander]

On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote:
> On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > At least an initial read suggests that you just multiplied the mirror
> > space requirements by however many times you use this trick.  I don't
> > believe infra's going to go for that.
> >
> 
> Yup - and everybody needs to mirror all the BINDISTs using all those
> older trees.  I don't think this is a good option all-around.
> 
> 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.
> 
> 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.
> 
> 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. 

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 ;)

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

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

[Brian Harring]

On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote:
> On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > At least an initial read suggests that you just multiplied the mirror
> > space requirements by however many times you use this trick. ?I don't
> > believe infra's going to go for that.
> >
> 
> 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.

This isn't that easy unfortunately; portage is indirectly eapi3 due to 
python.eclass; additionally, portage requires py2.6 and up (and isn't 
trivial restoring <2.6).

Paludis wise, it's eapi2 indirictely due to boost and eselect.  
Looking at the eapi depgraph for that, doesn't look particularly 
viable for upgrading from a EAPI<2 manager for paludis.  I'll leave 
it to Ciaran to comment on the feasability of a static rescue 
binary (or extremely simplified upgrade pathway).

For pkgcore, well, frankly it's a mild mess at the ebuild level- 
python.eclass induced (let's avoid the usual rants on that one also).  
Wasn't hugely happy to notice pkgcore was nudged to EAPI3; something 
I intend to rectify.

Intent is to restore it to EAPI0- frankly it really depends on what 
the python teams intentions are for EAPI0, currently that support is 
marked to be removed on "06/2011".  The rest of the indirect deps are 
either induced by the eclass, or stuff that can be disabled for 
bootstrapping (pyparsing is only required for `pquery --expr` for 
example; not exactly a critical feature).

Python version, in terms of upgrading:

if python2.4
 requires py2.4 and up, also requires pycrypto which was available on 
 all 2.4 installs anyways, so it can provide an EAPI upgrade pathway.
if python2.5:
 afaik, it should only require 2.5, nothing more.

At some point I'll probably drop py2.4 support, but that's likely in 
the years time scale.  I'd like to do so at some point, but the gains 
aren't big enough to warrant it (plus I'd then be doing a shit ton of 
refactoring to py2.5 minimum afterwards).

> 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.

To be clear, it's a bit more complex than that.  Simple example, 
if your system only supports EAPI2, in our tree it's rather unlikely 
you can jump directly forward to our current tree's ebuilds even if 
you've got binpkgs- as indicated above, eapi2/eapi3 usage for current 
ebuilds.  It might be possible, but I doubt that option is going 
to get any more feasible the longer time goes on.

Coincidentally, that fact also means that the proposal from wired to 
have multiple snapshots is basically dead in the water- not without 
very careful custom tree building for the old snapshot, all while 
trying to ensure that there is a direct jump from older versions to 
current.

To do this sort of upgrade, either you need extremely low deps (as 
I've wrote pkgcore for, despite the ebuilds deps), or you need a 
pretty damn careful ebuild upgrade pathway.  A 2.5/EAPI2 system would 
likely need to jump to a version of portage that had EAPI3, than jump 
to python2.6, than jump to latest portage (getting EAPI4), and than 
sorting out the depgraph conflicts for the upgrade (which afaik, is 
viable).

Note this also isn't talking about the bash 4.0 dep, although that one 
is lesser issue last I'd looked- bash ebuild is EAPI1, and the 
eclasses it consumes are fairly sane.


Either way, if desired it's reasonably straightforward to put 
together a tarball for this- roughly it's just snakeoil/pkgcore local 
checkout, upgrade bash, upgrade portage, upgrade portage, than use 
whatever PM you like. From that point, while the user likely has a 
mess to sort depgraph wise, it should at least be *possible* to do 
upgrades.

~harring

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Tue, 20 Sep 2011 03:28:48 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Paludis wise, it's eapi2 indirictely due to boost and eselect.  
> Looking at the eapi depgraph for that, doesn't look particularly 
> viable for upgrading from a EAPI<2 manager for paludis.  I'll leave 
> it to Ciaran to comment on the feasability of a static rescue 
> binary (or extremely simplified upgrade pathway).

boost's just for Python bindings, which are optional. The eselect
dependency is hard, and can't easily be made optional, so ideally
eselect should stick with older EAPIs.

Maybe we should stick something in metadata.xml...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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.

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

[Dirkjan Ochtman]

On Tue, Sep 20, 2011 at 12:28, Brian Harring <ferringb@gmail.com> wrote:
> Intent is to restore it to EAPI0- frankly it really depends on what
> the python teams intentions are for EAPI0, currently that support is
> marked to be removed on "06/2011".

We'd have to take a look at the complexity distribution, but I think
we can probably honor backwards compatibility a bit more than Arfrever
intended to.

> At some point I'll probably drop py2.4 support, but that's likely in
> the years time scale.  I'd like to do so at some point, but the gains
> aren't big enough to warrant it (plus I'd then be doing a shit ton of
> refactoring to py2.5 minimum afterwards).

We're seeing 2.4 support being dropped from packages at an increasing
pace since a few months.

Cheers,

Dirkjan

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

[Brian Harring]

On Tue, Sep 20, 2011 at 11:40:13AM +0100, Ciaran McCreesh wrote:
> On Tue, 20 Sep 2011 03:28:48 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > Paludis wise, it's eapi2 indirictely due to boost and eselect.  
> > Looking at the eapi depgraph for that, doesn't look particularly 
> > viable for upgrading from a EAPI<2 manager for paludis.  I'll leave 
> > it to Ciaran to comment on the feasability of a static rescue 
> > binary (or extremely simplified upgrade pathway).
> 
> boost's just for Python bindings, which are optional. The eselect
> dependency is hard, and can't easily be made optional, so ideally
> eselect should stick with older EAPIs.

Bit more than just that, going by a quick look.  libpcre is 3/4; 
looks like an old version is intentionally held back.  pkgconfig is 
the same- 0.25-r2 is EAPI2, everything else is EAPI4.

You didn't answer the static question btw...
~brian

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On Tue, 20 Sep 2011 04:07:44 -0700
Brian Harring <ferringb@gmail.com> wrote:
> You didn't answer the static question btw...

Because the answer's complicated!

The short version is, it could be made to work, if there's a need for
it, and so long as you've got gcc 4.5 for static libstdc++ support, but
it won't work right now.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]

El mar, 20-09-2011 a las 01:14 +0300, Alex Alexander escribió:
> EAPI in profiles and the -live version suffix are some of the improvements
> many people would like to see in the tree. Unfortunately, the risk of breaking
> systems with old versions of portage has been too high, holding evolution
> back.
> 
> I've been thinking about a way to solve this that would be easy to implement,
> without any significant compromises and one thing comes to mind:
> 
> Manipulation of the SYNC variable (i.e. rsync module),
> combined with tree snapshots.
> 
> At the moment, all systems have a SYNC line similar to this:
> 
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
> 
> My idea is simple. When incompatible changes have to be introduced to the
> tree, push a new version of portage that includes support for all the new
> features we want to provide.
> 
> Then, freeze the tree and clone it into a revbumped rsync module, i.e.
> 
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"
> 
> That way the last update provided by the old tree will be the updated portage
> package, which will be aware of the SYNC change.
> 
> After the user installs that update, every subsequent emerge run will print a
> fat red warning telling the user that the tree has been revbumped.
> 
> It will then provide instructions on how to update the make.conf/SYNC
> and a Y/N prompt to fix it itself. It could even do it automatically,
> but that's debatable.
> 
> By doing this we can be sure that any user using the revbumped SYNC have
> an up-to-date portage (if they cheated, well, that's their problem), allowing
> us to use all the new features provided by the latest version of portage.
> 
> For the above to work, we would require at least
> - support for multiple rsync modules pointing to different trees
>   [also in mirrors]
> - a way to freeze the current state of the tree for the current rsync module
>   and push future updates to a revbumped rsync module.
> - update our portage-snapshot tools to use the latest rsync module.
> - other things I'm probably forgetting right now
> 
> I'm not sure how much work would be required to make our current
> infrastructure support this, the infra people could shed some light on
> this.
> 
> The idea is to use this system sparingly, only when we need to push big
> changes that can't be supplied through an EAPI. Another example would be a
> change that would break the upgrade path. By freezing the tree at the right
> moment, we can be sure that the users will follow a known upgrade path
> that works.
> 
> Please keep in mind that my solution isn't trying to be the best thing
> possible. Instead, I'm aiming for something that would do the job and would be
> implemented in a realistic timeframe.
> 
> What do you guys think?

I haven't ever tried it but, what would occur if that people with really
updated systems simply unpack an updated stage3 tarball in their / and,
later, try to update?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3235 bytes --]

El mar, 20-09-2011 a las 15:09 +0200, Pacho Ramos escribió:
> El mar, 20-09-2011 a las 01:14 +0300, Alex Alexander escribió:
> > EAPI in profiles and the -live version suffix are some of the improvements
> > many people would like to see in the tree. Unfortunately, the risk of breaking
> > systems with old versions of portage has been too high, holding evolution
> > back.
> > 
> > I've been thinking about a way to solve this that would be easy to implement,
> > without any significant compromises and one thing comes to mind:
> > 
> > Manipulation of the SYNC variable (i.e. rsync module),
> > combined with tree snapshots.
> > 
> > At the moment, all systems have a SYNC line similar to this:
> > 
> > SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
> > 
> > My idea is simple. When incompatible changes have to be introduced to the
> > tree, push a new version of portage that includes support for all the new
> > features we want to provide.
> > 
> > Then, freeze the tree and clone it into a revbumped rsync module, i.e.
> > 
> > SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"
> > 
> > That way the last update provided by the old tree will be the updated portage
> > package, which will be aware of the SYNC change.
> > 
> > After the user installs that update, every subsequent emerge run will print a
> > fat red warning telling the user that the tree has been revbumped.
> > 
> > It will then provide instructions on how to update the make.conf/SYNC
> > and a Y/N prompt to fix it itself. It could even do it automatically,
> > but that's debatable.
> > 
> > By doing this we can be sure that any user using the revbumped SYNC have
> > an up-to-date portage (if they cheated, well, that's their problem), allowing
> > us to use all the new features provided by the latest version of portage.
> > 
> > For the above to work, we would require at least
> > - support for multiple rsync modules pointing to different trees
> >   [also in mirrors]
> > - a way to freeze the current state of the tree for the current rsync module
> >   and push future updates to a revbumped rsync module.
> > - update our portage-snapshot tools to use the latest rsync module.
> > - other things I'm probably forgetting right now
> > 
> > I'm not sure how much work would be required to make our current
> > infrastructure support this, the infra people could shed some light on
> > this.
> > 
> > The idea is to use this system sparingly, only when we need to push big
> > changes that can't be supplied through an EAPI. Another example would be a
> > change that would break the upgrade path. By freezing the tree at the right
> > moment, we can be sure that the users will follow a known upgrade path
> > that works.
> > 
> > Please keep in mind that my solution isn't trying to be the best thing
> > possible. Instead, I'm aiming for something that would do the job and would be
> > implemented in a realistic timeframe.
> > 
> > What do you guys think?
> 
> I haven't ever tried it but, what would occur if that people with really
> updated systems simply unpack an updated stage3 tarball in their / and,
> later, try to update?

updated -> outdated ;)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Tue, 20 Sep 2011 15:09:01 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> I haven't ever tried it but, what would occur if that people with
> really updated systems simply unpack an updated stage3 tarball in
> their / and, later, try to update?

Possibly at least few file collisions, if portage would be able to
clean the initial mess up.

But maybe a solution is to fork a minimalistic installer/updater from
portage which would have really tiny needs, unpack stage3 like you
suggested and then clean up remaining files from replaced packages.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

El mar, 20-09-2011 a las 15:16 +0200, Michał Górny escribió:
> On Tue, 20 Sep 2011 15:09:01 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > I haven't ever tried it but, what would occur if that people with
> > really updated systems simply unpack an updated stage3 tarball in
> > their / and, later, try to update?
> 
> Possibly at least few file collisions, if portage would be able to
> clean the initial mess up.
> 
> But maybe a solution is to fork a minimalistic installer/updater from
> portage which would have really tiny needs, unpack stage3 like you
> suggested and then clean up remaining files from replaced packages.
> 

Maybe we could tell that people to temporally disable protect-owned
FEATURE until update ends :-|

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ulrich Mueller]

>>>>> On Tue, 20 Sep 2011, Ciaran McCreesh wrote:

>> Paludis wise, it's eapi2 indirictely due to boost and eselect.

> The eselect dependency is hard, and can't easily be made optional,
> so ideally eselect should stick with older EAPIs.

Eselect's maintainer is well aware of this. I intend to keep 1.2.15
(which is EAPI 0) around for some time.

Ulrich

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

[Duncan]

Pacho Ramos posted on Tue, 20 Sep 2011 15:09:01 +0200 as excerpted:

> I haven't ever tried it but, what would occur if that people with really
> updated systems simply unpack an updated stage3 tarball in their / and,
> later, try to update?

I believe it was Mike that pointed me at the error in that, which once he 
mentioned it I recognized it due to having to recover from the same 
problem but for a different reason.[1]

The problem is that since the stage-3 untarring bypasses portage, the 
files on the live filesystem no longer match what portage believes to be 
installed.  The filesystem right after the untarring should be functional 
to at minimum the level of the stage tarball, but as soon as one starts 
emerging new packages, there will be issues since the old versions won't 
be properly removed, because the files no longer match what's in the 
database.

FEATURES=unmerge-orphans is a dramatic help cleaning up the mess (it 
wasn't around when I had the problem for other reasons, unfortunately), 
but I don't believe it can or will catch everything.

There's definitely a stage-3 tarball method that works and is actually 
the recommended method for updating real old installations, but it 
involves using a chroot and effectively installing from scratch in the 
chroot, then booting to it instead of the existing installation.  That's 
basically a special-case of case #5 in the Gentoo Linux Alternative 
Installation HOWTO, installing Gentoo from an existing Linux distro[2].  
The only bit of note is that the existing distro happens to be (an 
outdated) Gentoo as well, instead of whatever other distro.

---

[1] My situation was separate /, /usr and /var partitions, each with 
backups, but ending up in a recovery situation where the backups weren't 
in sync time-wise.  Thus portage's package installation database on /var 
was out of sync with the actual files on / and /usr.  I was still finding 
the occasional stale file triggering issues, over a year later!  It's for 
this reason that by personal policy, everything portage installs to is on 
the same partition, along with the installed package database, so if I 
end up using a backup of that partition, the database is by definition in 
sync with what's installed since it's all the same backup partition.


[2] http://www.gentoo.org/doc/en/altinstall.xml#doc_chap5

I used this HOWTO from Mandrake back in 2004, for my original
Gentoo/~amd64 install.  For that matter, the gentoo/amd64 32-bit chroot 
guide is a variant on this idea as well, except that for just a 32-bit 
chroot, the host-system kernel and services can be used, so they don't 
need built.  But I did a variant on /that/ for my netbook build image, 
located on my main machine since it's far more powerful than the netbook, 
and of course I built the kernel and system services for it, tho I only 
actually ran them after installing them to the netbook.
-- 
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

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3524 bytes --]

El mar, 20-09-2011 a las 13:57 +0000, Duncan escribió:
> Pacho Ramos posted on Tue, 20 Sep 2011 15:09:01 +0200 as excerpted:
> 
> > I haven't ever tried it but, what would occur if that people with really
> > updated systems simply unpack an updated stage3 tarball in their / and,
> > later, try to update?
> 
> I believe it was Mike that pointed me at the error in that, which once he 
> mentioned it I recognized it due to having to recover from the same 
> problem but for a different reason.[1]
> 
> The problem is that since the stage-3 untarring bypasses portage, the 
> files on the live filesystem no longer match what portage believes to be 
> installed.  The filesystem right after the untarring should be functional 
> to at minimum the level of the stage tarball, but as soon as one starts 
> emerging new packages, there will be issues since the old versions won't 
> be properly removed, because the files no longer match what's in the 
> database.
> 
> FEATURES=unmerge-orphans is a dramatic help cleaning up the mess (it 
> wasn't around when I had the problem for other reasons, unfortunately), 
> but I don't believe it can or will catch everything.
> 
> There's definitely a stage-3 tarball method that works and is actually 
> the recommended method for updating real old installations, but it 
> involves using a chroot and effectively installing from scratch in the 
> chroot, then booting to it instead of the existing installation.  That's 
> basically a special-case of case #5 in the Gentoo Linux Alternative 
> Installation HOWTO, installing Gentoo from an existing Linux distro[2].  
> The only bit of note is that the existing distro happens to be (an 
> outdated) Gentoo as well, instead of whatever other distro.
> 
> ---
> 
> [1] My situation was separate /, /usr and /var partitions, each with 
> backups, but ending up in a recovery situation where the backups weren't 
> in sync time-wise.  Thus portage's package installation database on /var 
> was out of sync with the actual files on / and /usr.  I was still finding 
> the occasional stale file triggering issues, over a year later!  It's for 
> this reason that by personal policy, everything portage installs to is on 
> the same partition, along with the installed package database, so if I 
> end up using a backup of that partition, the database is by definition in 
> sync with what's installed since it's all the same backup partition.
> 
> 
> [2] http://www.gentoo.org/doc/en/altinstall.xml#doc_chap5
> 
> I used this HOWTO from Mandrake back in 2004, for my original
> Gentoo/~amd64 install.  For that matter, the gentoo/amd64 32-bit chroot 
> guide is a variant on this idea as well, except that for just a 32-bit 
> chroot, the host-system kernel and services can be used, so they don't 
> need built.  But I did a variant on /that/ for my netbook build image, 
> located on my main machine since it's far more powerful than the netbook, 
> and of course I built the kernel and system services for it, tho I only 
> actually ran them after installing them to the netbook.

I thought that problem wouldn't occur as, if I don't misremember, stage3
tarballs include /var/db/pkg files for its packages and, then, an
"emerge -e world" just after unpacking stage3 would use
updated /var/db/pkg contents from stage3 and, for the remaining files,
they would be updated as soon as emerge -e world ends (maybe this and
"unmerge-orphans" would solved most of the issues)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Zac Medico]

On 09/19/2011 03:14 PM, Alex Alexander wrote:
> My idea is simple. When incompatible changes have to be introduced to the
> tree, push a new version of portage that includes support for all the new
> features we want to provide.
> 
> Then, freeze the tree and clone it into a revbumped rsync module, i.e.
> 
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"

It's a waste to provide the old copies via rsync. A similar alternative
that would solve that is to have a file in the tree that maps older
EAPIs to snapshots. That way, after a person syncs and finds that the
tree's EAPI is not supported, their package manager can easily locate
and download a tree snapshot (from any gentoo mirror) which is supported
by the current package manager.
-- 
Thanks,
Zac

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

[Zac Medico]

On 09/20/2011 08:19 AM, Zac Medico wrote:
> On 09/19/2011 03:14 PM, Alex Alexander wrote:
>> My idea is simple. When incompatible changes have to be introduced to the
>> tree, push a new version of portage that includes support for all the new
>> features we want to provide.
>>
>> Then, freeze the tree and clone it into a revbumped rsync module, i.e.
>>
>> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"
> 
> It's a waste to provide the old copies via rsync. A similar alternative
> that would solve that is to have a file in the tree that maps older
> EAPIs to snapshots. That way, after a person syncs and finds that the
> tree's EAPI is not supported, their package manager can easily locate
> and download a tree snapshot (from any gentoo mirror) which is supported
> by the current package manager.

Also, note that these snapshots really only need to contain the subset
of the tree that is needed to build a stage three with your current
package manager. You don't necessarily have to prune down the snapshot,
but at least you want to ensure that the essential stage three disfiles
remain mirrored so that the snapshots remain useful.
-- 
Thanks,
Zac

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

[Patrick Lauer]

On 09/20/11 15:09, Pacho Ramos wrote:
 > > What do you guys think?
> I haven't ever tried it but, what would occur if that people with really
> updated systems simply unpack an updated stage3 tarball in their / and,
> later, try to update?

Usually things turn ugly - used to be that portage saw that there are 
two glibcs installed and unmerges one (oh crummy, you only had one? 
better reinstall now ...) and other really disturbing side-effects.

Just unpacking a stage3 over a live system is a nice game, but rarely 
has sane results. You'd need to use a VDB-aware tool like qmerge to do 
it cleanly, and then you still don't have a working system (new glibc on 
old kernel, new udev on old kernel, lots of situations where things 
don't work out)

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

[Patrick Lauer]

On 09/20/11 17:19, Zac Medico wrote:
> On 09/19/2011 03:14 PM, Alex Alexander wrote:
>> My idea is simple. When incompatible changes have to be introduced to the
>> tree, push a new version of portage that includes support for all the new
>> features we want to provide.
>>
>> Then, freeze the tree and clone it into a revbumped rsync module, i.e.
>>
>> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"
> It's a waste to provide the old copies via rsync. A similar alternative
> that would solve that is to have a file in the tree that maps older
> EAPIs to snapshots. That way, after a person syncs and finds that the
> tree's EAPI is not supported, their package manager can easily locate
> and download a tree snapshot (from any gentoo mirror) which is supported
> by the current package manager.
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?)

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

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

On Sep 20, 2011 1:05 PM, "Patrick Lauer" <patrick@gentoo.org> 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.

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

[-- Attachment #2: Type: text/html, Size: 1247 bytes --]

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

[Alec Warner]

On Tue, Sep 20, 2011 at 10:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sep 20, 2011 1:05 PM, "Patrick Lauer" <patrick@gentoo.org> 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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Tue, 20 Sep 2011 10:48:37 -0700
Alec Warner <antarus@gentoo.org> wrote:

> On Tue, Sep 20, 2011 at 10:14 AM, Rich Freeman <rich0@gentoo.org>
> wrote:
> > On Sep 20, 2011 1:05 PM, "Patrick Lauer" <patrick@gentoo.org> 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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Duncan]

Patrick Lauer posted on Tue, 20 Sep 2011 19:00:38 +0200 as excerpted:

> On 09/20/11 15:09, Pacho Ramos wrote:
>  > > What do you guys think?
>> I haven't ever tried it but, what would occur if that people with
>> really updated systems simply unpack an updated stage3 tarball in their
>> / and, later, try to update?
> 
> Usually things turn ugly - used to be that portage saw that there are
> two glibcs installed and unmerges one (oh crummy, you only had one?
> better reinstall now ...) and other really disturbing side-effects.
> 
> Just unpacking a stage3 over a live system is a nice game, but rarely
> has sane results. You'd need to use a VDB-aware tool like qmerge to do
> it cleanly, and then you still don't have a working system (new glibc on
> old kernel, new udev on old kernel, lots of situations where things
> don't work out)

Thanks, this was far clearer (and more correct) than my attempt.

The point about old kernel incompatibilities is going to be especially 
valid on way outdated installations, and it's something I entirely 
missed, because especially with the kernel, I tend toward the leading 
edge rather than trailing, and because I bypass gentoo for the kernel 
entirely, using my own scripts and upstream git sources, so I don't tend 
to think in terms of gentoo/userspace kernel deps at all.

-- 
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

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

El mié, 21-09-2011 a las 04:00 +0000, Duncan escribió:
> Patrick Lauer posted on Tue, 20 Sep 2011 19:00:38 +0200 as excerpted:
> 
> > On 09/20/11 15:09, Pacho Ramos wrote:
> >  > > What do you guys think?
> >> I haven't ever tried it but, what would occur if that people with
> >> really updated systems simply unpack an updated stage3 tarball in their
> >> / and, later, try to update?
> > 
> > Usually things turn ugly - used to be that portage saw that there are
> > two glibcs installed and unmerges one (oh crummy, you only had one?
> > better reinstall now ...) and other really disturbing side-effects.
> > 
> > Just unpacking a stage3 over a live system is a nice game, but rarely
> > has sane results. You'd need to use a VDB-aware tool like qmerge to do
> > it cleanly, and then you still don't have a working system (new glibc on
> > old kernel, new udev on old kernel, lots of situations where things
> > don't work out)
> 
> Thanks, this was far clearer (and more correct) than my attempt.
> 
> The point about old kernel incompatibilities is going to be especially 
> valid on way outdated installations, and it's something I entirely 
> missed, because especially with the kernel, I tend toward the leading 
> edge rather than trailing, and because I bypass gentoo for the kernel 
> entirely, using my own scripts and upstream git sources, so I don't tend 
> to think in terms of gentoo/userspace kernel deps at all.
> 

Then, maybe people wanting to update really old systems should be guided
to get a precompiled updated kernel, probably the one used in liveCDs,
no?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]