| 1 |
On 04/05/2022 07.57, Ulrich Mueller wrote: |
| 2 |
>>>>>> On Wed, 04 May 2022, Florian Schmaus wrote: |
| 3 |
> |
| 4 |
>> + 5|6) inherit eutils ;; # eutils for eqawarn |
| 5 |
> |
| 6 |
> Adding eutils in 2022 seems a little backwards. Maybe make the output |
| 7 |
> command conditional instead? Something like this: |
| 8 |
> |
| 9 |
> # conditional needed in EAPIs 5 and 6 |
| 10 |
> local eqawarn=eqawarn |
| 11 |
> declare -F eqawarn >/dev/null || eqawarn=ewarn |
| 12 |
> ${eqawarn} ... |
| 13 |
> |
| 14 |
> Alternatively, port the few remaining EAPI 5 and 6 consumers to a newer |
| 15 |
> EAPI. :) |
| 16 |
|
| 17 |
This is being worked on. |
| 18 |
|
| 19 |
That said, I am not sure if a ewarn fallback is sensible. I was told |
| 20 |
eqawarn can be used to trigger tinderbox bugs, and that is exactly what |
| 21 |
we want, to see if there are any affected packages that we did not |
| 22 |
identify yet. And some of those potential packages are EAPI < 7. |
| 23 |
|
| 24 |
- Flow |
Archives