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