On Sun, 17 Jun 2012 12:51:50 +0200 Marien Zwart <mari...@gentoo.org> wrote:
> 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). Yes, you are right. > 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. Hmm, that is true. However, it all depends on how the utility would be called. As I see it, there are two possibilities here: a) utility is called using the currently selected Python version, b) utility is called using currently built Python version. In case (b) the complete dependency graph for that version of Python is probably required anyway. In case (a) indeed that may even cause the necessary version of the utility to be missing. First thought on handling this is to invent additional dependency symbol which would disable dynamic SLOTs for that particular dependency (opt-out seems to be simpler to handle globally than opt-in). > 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. Agreed. The next version of the spec (if the goal seemed still possible to achieve) will certainly have those. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
