1 |
On Fri, 7 Sep 2012 12:45:59 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner, |
5 |
> and since the Exherbo documentation doesn't seem to suffice to explain |
6 |
> the idea here, here's some more details on the DEPENDENCIES proposal. |
7 |
> |
8 |
> We observe that a typical package will have something like this: |
9 |
> |
10 |
> DEPEND=" |
11 |
> cat/first |
12 |
> cat/second |
13 |
> cat/third |
14 |
> cat/fourth |
15 |
> foo? ( |
16 |
> foo/one |
17 |
> >=foo/two-2.34[monkeys] |
18 |
> ) |
19 |
> bar? ( |
20 |
> bar/one |
21 |
> ) |
22 |
> baz? ( |
23 |
> baz/one |
24 |
> baz/two |
25 |
> ) |
26 |
> fnord? ( |
27 |
> fnord/one |
28 |
> )" |
29 |
> |
30 |
> RDEPEND=" |
31 |
> cat/second |
32 |
> cat/third |
33 |
> cat/fourth |
34 |
> cat/fifth |
35 |
> foo? ( |
36 |
> >=foo/two-2.34[monkeys] |
37 |
> foo/three |
38 |
> ) |
39 |
> bar? ( |
40 |
> bar/one |
41 |
> bar/two |
42 |
> bar/three |
43 |
> bar/four |
44 |
> )" |
45 |
|
46 |
Now please express that using bash variable references instead of |
47 |
the overly verbose expansions. Also, real examples are much more useful |
48 |
than counting and monkeys. This is not mathematics. |
49 |
|
50 |
> Note how many dependencies that we think of as being "the same" are |
51 |
> listed in two places, and are not in any way "the same". |
52 |
> |
53 |
> Note also how the foo-related things, the bar-related things etc |
54 |
> cannot be grouped together by their fooness or barness, but are |
55 |
> rather grouped by their DEPENDness and RDEPENDness. |
56 |
|
57 |
What is fooness and barness? Because I got lost near the four |
58 |
non-existent word. |
59 |
|
60 |
> Right now we've just got three variables. In a not too distant EAPI, |
61 |
> it will be considerably more than three. We also have duplication; |
62 |
> with HDEPEND, this will sometimes become triplication. |
63 |
|
64 |
Sometimes != always. Sometimes HDEPEND will actually simplify |
65 |
the current state. By moving a few things from DEPEND to HDEPEND, we |
66 |
may be actually able to remove COMMON_DEPEND. Sometimes. |
67 |
|
68 |
> Here's the important bit, which I shall prefix with some stars: |
69 |
> |
70 |
> *** The point of DEPENDENCIES is not to replace n variables with one |
71 |
> *** variable. |
72 |
|
73 |
Yes, it is. |
74 |
|
75 |
> *** The point of DEPENDENCIES is not to provide syntactic sugar over a |
76 |
> *** group of n variables. |
77 |
|
78 |
Yes, it is. |
79 |
|
80 |
> *** The point of DEPENDENCIES is to allow a package's dependencies, |
81 |
> *** which can be very complicated, to be expressed accurately and |
82 |
> *** simply, in a way friendly to how developers deal with dependencies |
83 |
> *** in practice. |
84 |
|
85 |
Didn't we already prove that the syntactic sugar DEPENDENCIES allows |
86 |
can make the dependency specifications very unclear and not anywhere |
87 |
close to simple? |
88 |
|
89 |
> So here's what DEPENDENCIES solves: |
90 |
> |
91 |
> Firstly, it allows developers to group together foo-related |
92 |
> dependencies and bar-related dependencies by their fooness and |
93 |
> barness, not by their role. |
94 |
> |
95 |
> Secondly, it reduces error-prone duplication. |
96 |
|
97 |
No, it doesn't. It just provides an alternate solution over how we do |
98 |
that now. Does variable substitution ring a bell? |
99 |
|
100 |
> Thirdly, it avoids some fairly obtuse names (BADEPEND? LDEPEND?) in |
101 |
> favour of something a tad more readable. |
102 |
|
103 |
That is a side effect. DEPENDENCIES doesn't disallow us from choosing |
104 |
to use labels like 'd:', 'r:'. Similarly, bash variables don't anyhow |
105 |
stand in the way of using more verbose names. |
106 |
|
107 |
> Here's the other important bit, with more stars: |
108 |
> |
109 |
> *** It does it by replacing the concept of "a package has build |
110 |
> *** dependencies, run dependencies, etc" with "a package has |
111 |
> *** dependencies, and each dependency is applicable at one or more of |
112 |
> *** build time, run tme, etc". |
113 |
|
114 |
Really? |
115 |
|
116 |
I think it actually gives concept of 'a package has a few random groups |
117 |
of dependencies, where each group is applicable at one or more of build |
118 |
time, run time, etc and consists of one or more dependencies or groups |
119 |
of dependencies, where each group is applicable at one or more of build |
120 |
time, run time, etc (which may or may not be the same as parent group) |
121 |
and consists of one or more dependencies or groups of dependencies, |
122 |
where each group is applicable at one or more of build time, run time, |
123 |
etc (which may or may not be the same as parent group) and consists of |
124 |
one or more dependencies or groups of dependencies, where each group is |
125 |
applicable at one or more of build time, run time, etc (which may or |
126 |
may not be the same as parent group) and consists of one or more |
127 |
dependencies or groups of dependencies, where each group is applicable |
128 |
at one or more of build time, run time, etc (which may or may not be |
129 |
the same as parent group) and consists of one or more dependencies or |
130 |
groups of dependencies, where each group is applicable at one or more |
131 |
of build time, run time, etc (which may or may not be the same as |
132 |
parent group) and consists ...' |
133 |
|
134 |
> We could just mark each dependency individually by when it's |
135 |
> applicable. But that turns out to be quite verbose, since packages |
136 |
> have fairly long lists of dependencies of the same kind. So here's a |
137 |
> much more concise syntax: |
138 |
> |
139 |
> DEPENDENCIES=" |
140 |
> build: |
141 |
> cat/first |
142 |
> build+run: |
143 |
> cat/second |
144 |
> cat/third |
145 |
> cat/fourth |
146 |
> run: |
147 |
> cat/fifth |
148 |
> |
149 |
> foo? ( |
150 |
> build: |
151 |
> foo/one |
152 |
> build+run: |
153 |
> >=foo/two-2.34[monkeys] |
154 |
> run: |
155 |
> foo/three |
156 |
> ) |
157 |
> |
158 |
> bar? ( |
159 |
> build+run: |
160 |
> bar/one |
161 |
> run: |
162 |
> bar/two |
163 |
> bar/three |
164 |
> bar/four |
165 |
> ) |
166 |
> |
167 |
> build: |
168 |
> baz? ( |
169 |
> baz/one |
170 |
> baz/two |
171 |
> ) |
172 |
> |
173 |
> fnord? ( |
174 |
> fnord/one |
175 |
> )" |
176 |
> |
177 |
> Here are the rules for working out which labels apply to a given spec: |
178 |
> |
179 |
> We have a "labels stack" when parsing. Initially, the value |
180 |
> "build+run" is on the top. Whenever we encounter a block ("( )", |
181 |
> "use? ( )" etc), we duplicate the top value of the stack, and when we |
182 |
> leave the block we pop the value off. Whenever we encounter labels, |
183 |
> we replace the top value on the stack with those labels. Whenever we |
184 |
> encounter a spec, its associated labels are those on the top of the |
185 |
> stack. |
186 |
|
187 |
These are the rules for a machine. People don't actually read |
188 |
dependencies sequentially. Provide a good algorithm which works from |
189 |
any position. |
190 |
|
191 |
> To avoid weirdness, so long as we're inside a || block, use of labels |
192 |
> is forbidden. Note that this is a reflection of the current ambiguity |
193 |
> as to what DEPEND="|| ( a b )" RDEPEND="|| ( a b )" means (can you |
194 |
> build against a, and run against b?), and if we're wanting to tidy |
195 |
> that up, that should be an independent proposal. |
196 |
|
197 |
Yes, that's something you could work on instead of throwing a lot of |
198 |
work on us just to reinvent the wheel your way because you believe that |
199 |
your bicycle is much better when it has square wheels. |
200 |
|
201 |
> These rules are mostly for flexibility: if developers sometimes prefer |
202 |
> to group things by role rather than by fooness, then that's possible |
203 |
> too. |
204 |
> |
205 |
> The rules for eclass merging need changing too, to add a ( ) around |
206 |
> values rather than merely appending. This is a technicality, and isn't |
207 |
> developer visible. |
208 |
|
209 |
The algorithm you presented above was technicality as well. |
210 |
|
211 |
So, now that your forked the thread shall we repeat all |
212 |
the disadvantages which you love to forgot to mention? |
213 |
|
214 |
-- |
215 |
Best regards, |
216 |
Michał Górny |