| 1 |
>>>>> On Thu, 23 Jun 2016, Dan Douglas wrote: |
| 2 |
|
| 3 |
>> That's the wrong way around. You should keep the EAPI version check |
| 4 |
>> but drop the check for the bash version. |
| 5 |
|
| 6 |
> I don't think that will work. You don't want this to vary by EAPI. |
| 7 |
|
| 8 |
Much less you want it to vary within a single EAPI, depending on |
| 9 |
package versions installed by the user. |
| 10 |
|
| 11 |
PMS defines the bash version for each EAPI for a reason. The spec even |
| 12 |
says that the shell's compatibility level should be set to the exact |
| 13 |
version specified if possible, so the intent is clear. Namely, ebuilds |
| 14 |
and eclasses are expected to stick to the features available in that |
| 15 |
bash version. Especially, they should not try to outsmart the spec by |
| 16 |
sniffing for the version of the shell themselves. |
| 17 |
|
| 18 |
> That aside, these variables are documented as being for |
| 19 |
> configuration and not part of the API for inheriting code. |
| 20 |
|
| 21 |
That sounds like the cleanest solution would be a git-r4 eclass |
| 22 |
supporting only EAPI 6 (or later). |
| 23 |
|
| 24 |
Ulrich |
Archives