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