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