Re: [gentoo-dev] [RFC] Dynamic SLOTs

[Marien Zwart]

On zo, 2012-06-17 at 09:26 +0200, Michał Górny wrote:
> I'm attaching a reStructuredText version of the spec. You can view it
> rendered as a gist[1]. But please keep the replies on the list, rather
> than forking the gist.

I've only thought about this a little, but some thoughts so far:

A common operation in an ebuild will be (say) "get the selected version
of python". That's easy enough if there's only one kind of dynamic slot
being used by the ebuild (just use CURRENT_SLOTS directly), but if the
ebuild supports more than one kind of dynamic slot you need a helper
function that picks the selected value of that one kind of slot out of
CURRENT_SLOTS, either relying on the naming scheme or on a list of
supported values of that kind of slot hardcoded in the helper function
(in an eclass). That seems a little fragile. Your "dynamic slot groups"
idea could help with this, by having that list sit in a more sensible
place than in an eclass, and perhaps by having the package mangler
provide a variable per slot group (a little like how USE_EXPAND works).

I really dislike the implicit dependencies. First of all: it is entirely
possible for ebuild A supporting dynamic slots for (say) python to have
a build-time dependency on ebuild B that supports dynamic slots (also
for python), but only to get at a utility to run, not to use B as a
library. In that case we don't want to force slots to match, and (as you
point out) that may not even be possible if the two packages don't
support the same slots. Also, it just breaks down completely if you
don't use your "slot groups" idea: if A has DYNAMIC_SLOTS="|| ( py2.6
py2.7 )" and B has DYNAMIC_SLOTS="|| ( ruby1.8 ruby1.9 )" it makes no
sense to require the dynamic slot setting to match, but if A has
DYNAMIC_SLOTS="|| ( py2.5 py2.6 )" and B has "|| ( py2.7 py3.2 )" then
we do need them to match, and the user has requested an impossible
situation (he needs to use versions of A and B that have at least one
supported python version in common). Without "slot groups" the package
manager cannot tell these two cases apart.

I think it'd make more sense to have those slot groups, per-slot group
variables like DYNAMIC_SLOTS_PYTHON="py2.7 py3.2" resulting in
CURRENT_SLOT_PYTHON getting set, and an addition to the dependency
syntax that lets you depend on a matching named dynamic slot. That makes
your DYNAMIC_SLOTS="|| ( py2.6 py2.7 ruby1.8 ruby1.9 )" example
impossible, but I think it'd be uncommon for that approach to make
sense: I think it'd usually make more sense to split that into two
packages, one per language.


-- 
Marien Zwart