Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Date: Fri, 19 Mar 2010 10:27:58
Message-Id: 20100319102742.GG28451@hrair
In Reply to: Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it by Ciaran McCreesh
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