1 |
On Fri, Mar 19, 2010 at 10:01:05AM +0000, Ciaran McCreesh wrote: |
2 |
> On Fri, 19 Mar 2010 02:56:08 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > > We are waiting on ABI dependencies (and extended support for |
5 |
> > > multiple ABIs in package manager), which will provide some needed |
6 |
> > > functionality. |
7 |
> > |
8 |
> > You can do it now w/out waiting on ABI dependencies- I'm not saying |
9 |
> > the dependencies would be pretty, but it's doable to get abi level |
10 |
> > depdencies per slotting via expanding out the use combinations. |
11 |
> > |
12 |
> > Note that's a step beyond what's in place now- converting over to the |
13 |
> > ruby abuse of USE_EXPAND hands over better control to users now w/ |
14 |
> > the same dep gurantees. |
15 |
> > |
16 |
> > So... yeah, it's not reliant on EAPI. An EAPI extension *would* make |
17 |
> > it easier, but it's not required to do it (especially since the deps |
18 |
> > are already autogenerated to a decent degree). |
19 |
> |
20 |
> How would do it and deal with existing packages not having the required |
21 |
> things in IUSE without (+)/(-) use deps? I don't see a way of doing it |
22 |
> legally without those. |
23 |
|
24 |
Roughly, |
25 |
|
26 |
PYTHON_DEPS="pkg1 pkg2 pkg3" |
27 |
SUPPORTED_PYTHONS="2.6 2.7 3.1" |
28 |
inherit insanely-unfriendly-trickery |
29 |
|
30 |
w/in said eclass, it does a few things |
31 |
|
32 |
1) IUSE addition of the USE_EXPAND targets for the supported abis |
33 |
2) take the enabled USE_EXPAND'd flags intersected against |
34 |
SUPPORTED_PYTHON, then set deps/rdeps to |
35 |
""" |
36 |
python_2.6? ( pkg1[python_2.6] pkg2[python_2.6] pkg3[python2.6] ) |
37 |
python_2.7? ( pkg1[python_2.7] pkg2[python_2.7] pkg3[python2.7] ) |
38 |
python_3.1? ( pkg1[python_3.1] pkg2[python_3.1] pkg3[python3.1] ) |
39 |
""" |
40 |
|
41 |
Yes, that is horrible (ciaran you knew it was going to be). Few flaws |
42 |
with it also- |
43 |
|
44 |
1) edge case when the user turns off all use flags needs addressing- |
45 |
worst case, python eclass forces whatever we consider the 'default' |
46 |
(aka 2.6) |
47 |
2) python_2.6 isn't actually a valid use flag- it would have to be |
48 |
python_2-6 or python_26 since periods aren't allowed (arfie pointed |
49 |
this out) |
50 |
3) this can be ugly for users if the PM doesn't treat use flags as |
51 |
tristate- specifically 'explicitly-set', 'explicitly-unset', |
52 |
'indeterminant'. If the ocnfiguration forces an explicit and it |
53 |
conflicts w/ the use dep, ok, configuration needs to be changed. If |
54 |
the use flag is indeterminant, then the PM needs to flip the flag on |
55 |
it's own in that case- I know pkgcore should do this, I don't think |
56 |
portage/paludis do (please correct me if wrong). |
57 |
|
58 |
|
59 |
Thing to note, the deps *would* be accurate- further at the vdb level |
60 |
they'd actually be usable. A dev-lang/python in the vdb is basically |
61 |
unusable since implicitly the pkg that has the dep is built against |
62 |
whatever slottings of python were available at the time- so if you |
63 |
take a pkg from now, a year down the line when py3.2 is stabled as far |
64 |
as the PM can tell that pkg *still* would work if <=py3.1 were removed |
65 |
(this obviously is not true). |
66 |
|
67 |
Note also that what I laid out above is as far as I know, going a |
68 |
couple of steps beyond what the ruby eclass does (same for what the |
69 |
python eclass does). I'm not necessarily advocating the approach |
70 |
above, but for the raw dev-lang/python dependency we *really* should |
71 |
be using use_expand there- it'll hand folk a fair amount of control as |
72 |
to what abi's get installed into. |
73 |
|
74 |
~harring |