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