1 |
On Fri, Sep 14, 2012 at 07:18:54AM +1200, Kent Fredric wrote: |
2 |
> On 11 September 2012 14:16, Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote: |
4 |
> >> Is there anything in particular in the spec/proposal for DEPENDENCIES |
5 |
> >> that would exclude the addition of individual "build: app-cat/myatom" |
6 |
> >> "run: app-cat/myatom" deps by an eclass or eclasses? I know the |
7 |
> >> "goal" here is to make things atom-centric, but I can't see an |
8 |
> >> implementation ever working of this that wouldn't permit the "pile-on" |
9 |
> >> of additional entries of different (or even the same) roles on |
10 |
> >> identical or near-identical atoms. |
11 |
> > |
12 |
> > They could be piled on; it would require each eclass to reset the |
13 |
> > label for safety reasons though; same goes for ebuilds frankly (or the |
14 |
> > PM would have to reset the context to build+run: each time through). |
15 |
> > |
16 |
> > Pardon if addressed elsewhere; this thread is a fucking mess... |
17 |
> > ~harring |
18 |
> > |
19 |
> Correct me if I'm wrong, but couldn't the entire proposition could be |
20 |
> implemented in an eclass, not needing the EAPI development cycle to be |
21 |
> tied up with it. |
22 |
> |
23 |
> All you need is something in bash that can parse DEPENDENCIES and |
24 |
> populate *DEPEND , and the underlying guts could be done in |
25 |
> practically any language without requiring PM specific |
26 |
> implementations. |
27 |
|
28 |
You've got it inverted; if any autopopulation is occuring, *DEPEND -> |
29 |
DEPENDENCIES is the sane form. |
30 |
|
31 |
While it definitely *is* possible to render DEPENDENCIES down into |
32 |
depend/rdepend (after all, the PM has to do exactly this for |
33 |
resolution), that does /not/ mean doing it in bash is a good idea. |
34 |
|
35 |
I'd really not want to try that using labels; using use conditionals |
36 |
('dep:run,build? ( targets )') is frankly a bit easier imo, but still; |
37 |
why do so unless one likes pain? It doesn't actually gain us |
38 |
anything via missing the point of DEPENDENCIES. |
39 |
|
40 |
The point of unified DEPENDENCIES var (regardless of the form) is |
41 |
thus: |
42 |
1) ability to specify common deps once, w/out having to use |
43 |
intermediate vars/copy-pasting/etc. Think COMMON_DEPEND, and this |
44 |
should make sense. |
45 |
|
46 |
2) To shift to a form where adding new dependency targets is easy- |
47 |
whether it be sdepend, fdepend, tdepend, or hdepend (or |
48 |
ONE-RING-DEPEND to rule them all). This actually is rather important; |
49 |
for the average 95% case, devs won't actually have to pay much |
50 |
attention to those vars; but for those of us a bit further out (cross |
51 |
compilation, heavy parallelization, etc) those depend forms are |
52 |
becoming increasingly painful in their absense. |
53 |
|
54 |
|
55 |
Basically, having devs specify DEPENDENCIES in ebuilds, which then an |
56 |
eclass chunks out into DEPEND/RDEPEND misses the point of this; it's |
57 |
doable, it's just not particularly sane imo. |
58 |
|
59 |
The other way around, having *DEPEND automatically be collapsed into |
60 |
DEPENDENCIES, however is very sane- it makes transition/compatibilty |
61 |
for devs bloody simple, while structuring it so we can do further |
62 |
enhancements. |
63 |
|
64 |
~harring |