1 |
On Sun, 16 Sep 2012 06:52:11 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> The live version of the doc is available at |
4 |
> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html |
5 |
|
6 |
I think you're being a bit glib with your dismissal of the labels |
7 |
parsing scheme. You've got the following problems, that labels don't |
8 |
have: |
9 |
|
10 |
You dismiss the dep:build? ( dep:run? ( ) ) problem as "don't do that". |
11 |
Labels doesn't have this problem: it doesn't try to reuse an existing |
12 |
syntax precisely because the existing syntax is extremely awkward for |
13 |
this kind of thing. |
14 |
|
15 |
You say there's an implict "build,run". This can't be an implicit |
16 |
"dep:build,run? ( )" using that syntax, however, since then you |
17 |
wouldn't be able to put a dep:post? inside it by the above. So again |
18 |
you've got a special case to deal with simply because of the syntax -- |
19 |
your syntax doesn't correspond directly to the meaning of dependencies. |
20 |
|
21 |
There's also the issue of what negations do at the top level... |
22 |
|
23 |
You discourage grouping of dependencies by the use flag that selects |
24 |
them (see xscreensaver in your examples). Logically, "xscreensaver |
25 |
related things" belong together. Your negation example also tries to |
26 |
bring related dependencies together. But it's a mess. What if one of |
27 |
the dependencies was a build dependency, and one a run dependency? |
28 |
You'd end up with something silly like this: |
29 |
|
30 |
dep:build,run? ( |
31 |
!dep:run? ( dev-util/diffball ) |
32 |
!dep:build? ( dev-util/bsdiff ) |
33 |
) |
34 |
|
35 |
Your syntax also prevents the following: |
36 |
|
37 |
DEPENDENCIES="foo? ( $(make_foo_deps blah) )" |
38 |
|
39 |
and would encourage something like this instead: |
40 |
|
41 |
DEPENDENCIES=" |
42 |
dep:build? ( foo? ( $(make_foo_build_deps blah) ) ) |
43 |
dep:run? ( foo? ( $(make_foo_run_deps blah) ) ) |
44 |
dep:build,run? ( foo? ( $(make_foo_build_and_run_deps blah) ) ) |
45 |
|
46 |
which makes it much harder for the foo.eclass authors to switch what |
47 |
kinds of dependencies they use. For example, if foo.eclass starts |
48 |
needing an install dependency, your syntax requires every foo user to |
49 |
be updated, whereas labels does not. To get around that, you'd have to |
50 |
allow deeply embedded dep: blocks. |
51 |
|
52 |
You're also still speaking in terms of "rendering DEPEND" etc. That's |
53 |
not really what we want, though. As you've observed, a lot of atoms are |
54 |
in both DEPEND and RDEPEND. Conceptually, it makes much more sense to |
55 |
consider such an atom to be a single dependency that is both a build |
56 |
and a runtime dependency than it does to consider it as two unrelated |
57 |
dependencies. This is especially the case now that we have := slot |
58 |
dependencies. |
59 |
|
60 |
Ultimately, it comes down to the observation that the flag? ( ) syntax |
61 |
is strongly nested and hierarchical, but dependency roles aren't. |
62 |
Labels can give all the advantages of your proposal (including the |
63 |
backwards compatibility, if that's desired), but without the need to |
64 |
shoehorn the idea into an unsuitable syntax. |
65 |
|
66 |
-- |
67 |
Ciaran McCreesh |