Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 10:29:34
Message-Id: 20110920102848.GA6252@localhost
In Reply to: Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Rich Freeman
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@×××.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