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 |