1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
2 |
Hash: SHA1
|
3 |
|
4 |
On Fri, 23 Mar 2012 12:32:05 -0400
|
5 |
Ian Stakenvicius <axs@g.o> wrote:
|
6 |
|
7 |
> -----BEGIN PGP SIGNED MESSAGE----- |
8 |
> Hash: SHA256 |
9 |
> |
10 |
> On 23/03/12 12:19 PM, Ciaran McCreesh wrote: |
11 |
> > On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius |
12 |
> > <axs@g.o> wrote: |
13 |
> >> I don't know if I follow this one or not. When inheriting an |
14 |
> >> eclass, all entities within the eclass get merged into the |
15 |
> >> ebuild. As long as there aren't any special conditional tricks |
16 |
> >> being used to assign to global variables like IUSE, it would |
17 |
> >> still be invariant wouldn't it? |
18 |
> > |
19 |
> > The point is that the merging might be done inside the package |
20 |
> > manager (not in bash code) on the IUSE metadata variable, and the |
21 |
> > changes don't have to be reflected in the IUSE environment variable |
22 |
> > inside the ebuild. |
23 |
> |
24 |
> If that was the case, then eclasses could no longer append deps to |
25 |
> (R)DEPEND, either .....? |
26 |
|
27 |
The point of the wording is to allow an eclass to do this:
|
28 |
|
29 |
DEPEND="cat/two"
|
30 |
|
31 |
and an ebuild do this:
|
32 |
|
33 |
DEPEND="cat/one"
|
34 |
|
35 |
and to have the package manager, but not necessarily bash code, know
|
36 |
that there are two dependencies. It also makes the annoying RDEPEND
|
37 |
value behaviour that older EAPIs specify possible.
|
38 |
|
39 |
So yes, you *could* argue that with the way it's worded, this in an
|
40 |
eclass isn't guaranteed to work:
|
41 |
|
42 |
DEPEND="cat/three"
|
43 |
DEPEND="${DEPEND} cat/four"
|
44 |
|
45 |
What the wording is supposed to imply is that if some bash code looks
|
46 |
at DEPEND, it could contain either "cat/three cat/four", or "cat/one
|
47 |
cat/three cat/four". If the first DEPEND looked like the second, then
|
48 |
it would also be allowed to contain "cat/one cat/one cat/three
|
49 |
cat/four" and similar.
|
50 |
|
51 |
What this really comes down to is that bash is the wrong tool for doing
|
52 |
what we're doing, and that we can't have this work "the way we want
|
53 |
it to" since bash doesn't provide the interfaces we need to get it
|
54 |
to work, and every time we try to be clever it breaks on newer bash
|
55 |
releases...
|
56 |
|
57 |
- --
|
58 |
Ciaran McCreesh
|
59 |
-----BEGIN PGP SIGNATURE-----
|
60 |
Version: GnuPG v2.0.18 (GNU/Linux)
|
61 |
|
62 |
iEYEARECAAYFAk9sqFAACgkQ96zL6DUtXhFnJgCfZhLF1/UsWWCARATI2I9pg5Yv
|
63 |
ATMAn3exnOUWgwQTt84v1q9mE9ptOiH/
|
64 |
=BQ2n
|
65 |
-----END PGP SIGNATURE----- |