| 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----- |
Archives