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
