-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 23 Mar 2012 12:32:05 -0400
Ian Stakenvicius <a...@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 23/03/12 12:19 PM, Ciaran McCreesh wrote:
> > On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius
> > <a...@gentoo.org> wrote:
> >> I don't know if I follow this one or not.  When inheriting an
> >> eclass, all entities within the eclass get merged into the
> >> ebuild.  As long as there aren't any special conditional tricks
> >> being used to assign to global variables like IUSE, it would
> >> still be invariant wouldn't it?
> > 
> > The point is that the merging might be done inside the package
> > manager (not in bash code) on the IUSE metadata variable, and the
> > changes don't have to be reflected in the IUSE environment variable
> > inside the ebuild.
> 
> If that was the case, then eclasses could no longer append deps to
> (R)DEPEND, either .....?

The point of the wording is to allow an eclass to do this:

    DEPEND="cat/two"

and an ebuild do this:

    DEPEND="cat/one"

and to have the package manager, but not necessarily bash code, know
that there are two dependencies. It also makes the annoying RDEPEND
value behaviour that older EAPIs specify possible.

So yes, you *could* argue that with the way it's worded, this in an
eclass isn't guaranteed to work:

    DEPEND="cat/three"
    DEPEND="${DEPEND} cat/four"

What the wording is supposed to imply is that if some bash code looks
at DEPEND, it could contain either "cat/three cat/four", or "cat/one
cat/three cat/four". If the first DEPEND looked like the second, then
it would also be allowed to contain "cat/one cat/one cat/three
cat/four" and similar.

What this really comes down to is that bash is the wrong tool for doing
what we're doing, and that we can't have this work "the way we want
it to" since bash doesn't provide the interfaces we need to get it
to work, and every time we try to be clever it breaks on newer bash
releases...

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9sqFAACgkQ96zL6DUtXhFnJgCfZhLF1/UsWWCARATI2I9pg5Yv
ATMAn3exnOUWgwQTt84v1q9mE9ptOiH/
=BQ2n
-----END PGP SIGNATURE-----

Reply via email to