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
1 On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote:
2 > On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.duncan@×××.net> wrote:
3 > > At least an initial read suggests that you just multiplied the mirror
4 > > space requirements by however many times you use this trick. ?I don't
5 > > believe infra's going to go for that.
6 > >
7 >
8 > The only real gotcha is if portage is so old that it can't handle the
9 > binary packages. However, to get around that we really just need a
10 > set of step-wise binary updates for portage itself so that you can
11 > sequence it up to something that can install the rest. That will work
12 > as long as portage doesn't strictly need a newer dependency. If it
13 > needs a newer python or something then we might need to keep a binary
14 > package of that lying around - maybe statically linked so that it
15 > doesn't go further than a few packages.
16
17 This isn't that easy unfortunately; portage is indirectly eapi3 due to
18 python.eclass; additionally, portage requires py2.6 and up (and isn't
19 trivial restoring <2.6).
20
21 Paludis wise, it's eapi2 indirictely due to boost and eselect.
22 Looking at the eapi depgraph for that, doesn't look particularly
23 viable for upgrading from a EAPI<2 manager for paludis. I'll leave
24 it to Ciaran to comment on the feasability of a static rescue
25 binary (or extremely simplified upgrade pathway).
26
27 For pkgcore, well, frankly it's a mild mess at the ebuild level-
28 python.eclass induced (let's avoid the usual rants on that one also).
29 Wasn't hugely happy to notice pkgcore was nudged to EAPI3; something
30 I intend to rectify.
31
32 Intent is to restore it to EAPI0- frankly it really depends on what
33 the python teams intentions are for EAPI0, currently that support is
34 marked to be removed on "06/2011". The rest of the indirect deps are
35 either induced by the eclass, or stuff that can be disabled for
36 bootstrapping (pyparsing is only required for `pquery --expr` for
37 example; not exactly a critical feature).
38
39 Python version, in terms of upgrading:
40
41 if python2.4
42 requires py2.4 and up, also requires pycrypto which was available on
43 all 2.4 installs anyways, so it can provide an EAPI upgrade pathway.
44 if python2.5:
45 afaik, it should only require 2.5, nothing more.
46
47 At some point I'll probably drop py2.4 support, but that's likely in
48 the years time scale. I'd like to do so at some point, but the gains
49 aren't big enough to warrant it (plus I'd then be doing a shit ton of
50 refactoring to py2.5 minimum afterwards).
51
52 > Something like that really just needs a few tarballs and then an
53 > up-to-date set of binary stage3 packages. The binary packages could
54 > be built at the same time the stage3s are made. And, this is really
55 > just a contingency plan so we don't need to mirror all that stuff - we
56 > could even just make it torrent-only or something.
57
58 To be clear, it's a bit more complex than that. Simple example,
59 if your system only supports EAPI2, in our tree it's rather unlikely
60 you can jump directly forward to our current tree's ebuilds even if
61 you've got binpkgs- as indicated above, eapi2/eapi3 usage for current
62 ebuilds. It might be possible, but I doubt that option is going
63 to get any more feasible the longer time goes on.
64
65 Coincidentally, that fact also means that the proposal from wired to
66 have multiple snapshots is basically dead in the water- not without
67 very careful custom tree building for the old snapshot, all while
68 trying to ensure that there is a direct jump from older versions to
69 current.
70
71 To do this sort of upgrade, either you need extremely low deps (as
72 I've wrote pkgcore for, despite the ebuilds deps), or you need a
73 pretty damn careful ebuild upgrade pathway. A 2.5/EAPI2 system would
74 likely need to jump to a version of portage that had EAPI3, than jump
75 to python2.6, than jump to latest portage (getting EAPI4), and than
76 sorting out the depgraph conflicts for the upgrade (which afaik, is
77 viable).
78
79 Note this also isn't talking about the bash 4.0 dep, although that one
80 is lesser issue last I'd looked- bash ebuild is EAPI1, and the
81 eclasses it consumes are fairly sane.
82
83
84 Either way, if desired it's reasonably straightforward to put
85 together a tarball for this- roughly it's just snakeoil/pkgcore local
86 checkout, upgrade bash, upgrade portage, upgrade portage, than use
87 whatever PM you like. From that point, while the user likely has a
88 mess to sort depgraph wise, it should at least be *possible* to do
89 upgrades.
90
91 ~harring

Replies