On 06/23/2016 09:15 AM, Ulrich Mueller wrote: >>>>>> On Thu, 23 Jun 2016, Dan Douglas wrote: > >> Well I just dropped the EAPI check since it was pointless anyway. > >> https://github.com/gentoo/gentoo/pull/1723/commits/3ebc1f57378a5ed4a62232ac87a0955ccdd33a4d > > That's the wrong way around. You should keep the EAPI version check > but drop the check for the bash version.
I don't think that will work. You don't want this to vary by EAPI. For instance
I was using this for merging a set and wanted all of its packages to check out a
particular tag without having to care about which EAPI is used by each package.
All that matters is that it's consistent system-wide.
> PMS clearly defines the bash
> version for each EAPI (namely, bash-3.2 for EAPI 0 to 5 and bash-4.2
> for EAPI 6).
Ok. FWIW this is valid bash 3 and 4 code. I don't think it's so clear what that
means for eclass shared code.
The API exposed here is still invariant. It's typically the responsibility of
the calling code to know whether the current environment supports a particular
datatype before attempting to use it, and not a requirement for library code to
refuse handling that type (like through some ad-hoc polymorphism) when
requested unless doing so would somehow break backwards-compatibility.
That aside, these variables are documented as being for configuration and not
part of the API for inheriting code.
I won't fight too hard if you really hate this, but the previous ${PN}_var is
pretty ugly. The `s/[+-]/_/` name mangling rule wasn't even documented, which
was what got me looking at this code in the first place.
signature.asc
Description: OpenPGP digital signature
