| 1 |
On 10/19/2012 07:23 AM, Gregory M. Turner wrote: |
| 2 |
> I'm cooking up some eclass functions and it occurred to me that perhaps |
| 3 |
> I had some responsibility regarding EAPI4's new error handling |
| 4 |
> semantics. After looking into it, it seems that, superficially, the |
| 5 |
> answer to my question is "no, the EAPI4 changes only apply to ebuild |
| 6 |
> helpers." |
| 7 |
> |
| 8 |
> Even so, this got me thinking: if ebuild helpers are going to warn(*) in |
| 9 |
> EAPI<4 and die in EAPI>=4 (unless somebody used "nonfatal"), then, those |
| 10 |
> error-handling semantics are going to bubble up through my eclass to its |
| 11 |
> heirs (assuming my eclass uses helpers). |
| 12 |
|
| 13 |
Regardless of EAPI, don't call the helpers that die in EAPI 4 unless you |
| 14 |
want the function to die when the helpers fail, and use helper || die so |
| 15 |
it behaves the same regardless of EAPI. It's okay to die in older EAPIs, |
| 16 |
as long as you're not changing the behavior of a previously existing |
| 17 |
eclass function. Previously existing eclass functions that only start to |
| 18 |
die in EAPI 4 are okay, since they only start to die when the ebuild |
| 19 |
developer bumps the EAPI. |
| 20 |
-- |
| 21 |
Thanks, |
| 22 |
Zac |
Archives