1 |
On Sun, 17 Jun 2012 12:51:50 +0200 |
2 |
Marien Zwart <marienz@g.o> wrote: |
3 |
|
4 |
> A common operation in an ebuild will be (say) "get the selected |
5 |
> version of python". That's easy enough if there's only one kind of |
6 |
> dynamic slot being used by the ebuild (just use CURRENT_SLOTS |
7 |
> directly), but if the ebuild supports more than one kind of dynamic |
8 |
> slot you need a helper function that picks the selected value of that |
9 |
> one kind of slot out of CURRENT_SLOTS, either relying on the naming |
10 |
> scheme or on a list of supported values of that kind of slot |
11 |
> hardcoded in the helper function (in an eclass). That seems a little |
12 |
> fragile. Your "dynamic slot groups" idea could help with this, by |
13 |
> having that list sit in a more sensible place than in an eclass, and |
14 |
> perhaps by having the package mangler provide a variable per slot |
15 |
> group (a little like how USE_EXPAND works). |
16 |
|
17 |
Yes, you are right. |
18 |
|
19 |
> I really dislike the implicit dependencies. First of all: it is |
20 |
> entirely possible for ebuild A supporting dynamic slots for (say) |
21 |
> python to have a build-time dependency on ebuild B that supports |
22 |
> dynamic slots (also for python), but only to get at a utility to run, |
23 |
> not to use B as a library. In that case we don't want to force slots |
24 |
> to match, and (as you point out) that may not even be possible if the |
25 |
> two packages don't support the same slots. |
26 |
|
27 |
Hmm, that is true. However, it all depends on how the utility would be |
28 |
called. As I see it, there are two possibilities here: |
29 |
|
30 |
a) utility is called using the currently selected Python version, |
31 |
b) utility is called using currently built Python version. |
32 |
|
33 |
In case (b) the complete dependency graph for that version of Python is |
34 |
probably required anyway. In case (a) indeed that may even cause |
35 |
the necessary version of the utility to be missing. |
36 |
|
37 |
First thought on handling this is to invent additional dependency |
38 |
symbol which would disable dynamic SLOTs for that particular dependency |
39 |
(opt-out seems to be simpler to handle globally than opt-in). |
40 |
|
41 |
> Also, it just breaks down |
42 |
> completely if you don't use your "slot groups" idea: if A has |
43 |
> DYNAMIC_SLOTS="|| ( py2.6 py2.7 )" and B has DYNAMIC_SLOTS="|| |
44 |
> ( ruby1.8 ruby1.9 )" it makes no sense to require the dynamic slot |
45 |
> setting to match, but if A has DYNAMIC_SLOTS="|| ( py2.5 py2.6 )" and |
46 |
> B has "|| ( py2.7 py3.2 )" then we do need them to match, and the |
47 |
> user has requested an impossible situation (he needs to use versions |
48 |
> of A and B that have at least one supported python version in |
49 |
> common). Without "slot groups" the package manager cannot tell these |
50 |
> two cases apart. |
51 |
> |
52 |
> I think it'd make more sense to have those slot groups, per-slot group |
53 |
> variables like DYNAMIC_SLOTS_PYTHON="py2.7 py3.2" resulting in |
54 |
> CURRENT_SLOT_PYTHON getting set, and an addition to the dependency |
55 |
> syntax that lets you depend on a matching named dynamic slot. That |
56 |
> makes your DYNAMIC_SLOTS="|| ( py2.6 py2.7 ruby1.8 ruby1.9 )" example |
57 |
> impossible, but I think it'd be uncommon for that approach to make |
58 |
> sense: I think it'd usually make more sense to split that into two |
59 |
> packages, one per language. |
60 |
|
61 |
Agreed. The next version of the spec (if the goal seemed still possible |
62 |
to achieve) will certainly have those. |
63 |
|
64 |
-- |
65 |
Best regards, |
66 |
Michał Górny |