1 |
On Thu, 6 Sep 2012 09:39:25 +0200 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
> On Thu, 6 Sep 2012 06:58:51 +0100 |
4 |
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
5 |
> > On Wed, 5 Sep 2012 18:15:43 +0200 |
6 |
> > Michał Górny <mgorny@g.o> wrote: |
7 |
> > > If we really want to go this route, then please at least require |
8 |
> > > explicit label at start of DEPENDENCIES. And the same when |
9 |
> > > appending to DEPENDENCIES -- just so 'unlikely' mistakes will |
10 |
> > > leave us with hours of debugging. |
11 |
> > |
12 |
> > We should take the exheres-0 rules for labels and eclasses, which |
13 |
> > limit labels' scopes to blocks, and which introduce an extra ( ) |
14 |
> > block around the outside when doing eclass variable merging. |
15 |
> |
16 |
> Because? I believe we should take 'Gentoo rules', including required |
17 |
> explicit build+run at the start. |
18 |
|
19 |
You mean, you want to invent some new rules that don't quite work, |
20 |
rather than using the ones that do... The whole "initial labels" thing |
21 |
isn't an issue for exheres-0, since rather than appending, the |
22 |
resulting metadata variable ends up with extra ( ) blocks like this: |
23 |
|
24 |
( |
25 |
stuff/from-the-exheres |
26 |
) |
27 |
( |
28 |
stuff/from-exlib-1 |
29 |
) |
30 |
( |
31 |
stuff/from-exlib-2 |
32 |
) |
33 |
|
34 |
so there's no possibility of labels ending up applied to the wrong |
35 |
thing. |
36 |
|
37 |
If you just append, you'd have to have some way of validating that |
38 |
eclasses all individually specify an initial label. That's not |
39 |
something that can easily be done. |
40 |
|
41 |
> > (And I have a sneaking recollection of PMS not documenting this |
42 |
> > properly...) |
43 |
> |
44 |
> Yes, I think PMS is pretty silent about this. I think it doesn't even |
45 |
> say that in phase functions the contents are implementation-defined. |
46 |
|
47 |
That's covered under the general rules for environment variables. The |
48 |
issue is that PMS doesn't make a good distinction between the metadata |
49 |
variable's value and the environment variable value. The wording that's |
50 |
in there currently dates back to how things worked a very long time ago. |
51 |
|
52 |
> > > Remember that this requirement will actually cause migration to |
53 |
> > > EAPI 5 to be even harder than to any previous EAPIs. Migrating a |
54 |
> > > single ebuild will require rewriting the dependencies, and |
55 |
> > > migrating an eclass will require adding a lot of dirty code. |
56 |
> > |
57 |
> > Migrating to EAPI 5 requires rewriting dependencies anyway if we're |
58 |
> > adding in HDEPEND. Also, earlier EAPIs have introduced new phase |
59 |
> > functions, which is a far ickier change for ebuilds than this. |
60 |
> |
61 |
> Do you really believe in HDEPEND in EAPI 5? I've already postponed |
62 |
> this in my mind. Also, not every single ebuild will actually need it. |
63 |
|
64 |
*shrug* if all the new *DEPEND stuff ends up in EAPI 6, then there's no |
65 |
point in DEPENDENCIES for EAPI 5. But we'll have to sort this out |
66 |
sooner or later... |
67 |
|
68 |
> > > And we will have to convert them back to old-style dependencies |
69 |
> > > anyway. For the sake of compatibility with external tools. |
70 |
> > |
71 |
> > No, external tools are required to be EAPI aware. If they're not, |
72 |
> > then the external tools need fixing. |
73 |
> |
74 |
> Changing package manager API like that between EAPI is just bad. You |
75 |
> know that, don't you? |
76 |
|
77 |
Your choices are to make the package manager API abstract out this sort |
78 |
of thing, or to require client updates for a new EAPI. And as it's |
79 |
fairly hard to predict what's going to be in a new EAPI, being too |
80 |
abstract is pretty much a lost cause. |
81 |
|
82 |
You can't simply convert new concepts to old concepts, since there's no |
83 |
pre-EAPI-5 concept of what any of these new dependency types are. |
84 |
Treating an HDEPEND or an IDEPEND as a DEPEND is just wrong. |
85 |
|
86 |
-- |
87 |
Ciaran McCreesh |