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

[Brian Harring <ferringb@gmail.com>]

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