1 |
On 10/20/2012 03:51 PM, Gregory M. Turner wrote: |
2 |
> On 10/20/2012 11:16 AM, Zac Medico wrote: |
3 |
>> On 10/20/2012 03:52 AM, Gregory M. Turner wrote: |
4 |
>>> EAPI[0-3] conventions encourage the habit of writing ebuild code like |
5 |
>>> |
6 |
>>> invoke_fn || ... # handle error, probably by die()ing but maybe not |
7 |
>>> |
8 |
>>> But eclasses that auto-die violate this expectation and create a |
9 |
>>> situation where ebuild authors must be mindful of whether a particular |
10 |
>>> function is a helper-function or an eclass utility function to correctly |
11 |
>>> anticipate whether auto-death will occur. |
12 |
>>> |
13 |
>>> should we really write new eclass code to behave this way as well? |
14 |
>> |
15 |
>> Yeah, I think we should. If the eclass function is doing something that |
16 |
>> might result in an undesirable die, then it can try to avoid the die by |
17 |
>> first doing a sanity check. For example, it can check that a given file |
18 |
>> path exists before passing it to the helper, and skip calling the helper |
19 |
>> if the file path doesn't exist. |
20 |
> |
21 |
> That seems reasonable -- in practice, I don't find myself needing to |
22 |
> invoke helpers very much at all in eclasses, nor does it seem too |
23 |
> terribly frequent in the existing eclasses (dodir is pretty common, but |
24 |
> unlikely to fail unless something is seriously wrong anyhow). |
25 |
> |
26 |
> Would it be feasible to lift the >=EAPI4 restriction on nonfatal()? I |
27 |
> guess the problem would be that old portage's wouldn't have it. |
28 |
|
29 |
No. The closest thing you can do is drop support for older EAPIs in your |
30 |
eclass (just die in global scope at the beginning of the eclass if the |
31 |
EAPI is unsupported). |
32 |
|
33 |
> Anyhow, given that eclasses can probably avoid auto-die() if they need |
34 |
> to, this leaves the issue of nonfatal allowing die to return to |
35 |
> callers... is there really any reason that die() needs to work this way? |
36 |
> If helpers always used __helpers_die() instead of die(), then couldn't |
37 |
> die() be changed to ignore PORTAGE_NONFATAL? |
38 |
|
39 |
Yes. It's a bug, as Ciaran said. |
40 |
|
41 |
> It almost seems like the portage code was designed for nonfatal only to |
42 |
> apply to helper invocations, and then the change to die() was added as |
43 |
> an afterthought, to support the broader range of usages suggested |
44 |
|
45 |
You can see here that the special die() behavior was added in the same |
46 |
commit when nonfatal() was added: |
47 |
|
48 |
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d8d45379b52f5330c6cec616d675706eb0ba2599 |
49 |
|
50 |
> (rather vaguely, I'd say) by the language in the PMS, ... yet somehow, |
51 |
> the PMS ends up strongly suggesting -- I think most people would read |
52 |
> the language as an explicit specification -- that ebuilds can rely on |
53 |
> die() to terminate regardless of any usage of nonfatal. |
54 |
|
55 |
Yeah, I think portage's special die() behavior is clearly a bug. |
56 |
-- |
57 |
Thanks, |
58 |
Zac |