Re: [gentoo-dev] eclass error-handling post-EAPI4

[Zac Medico]

On 10/20/2012 02:24 PM, Gregory M. Turner wrote:
> On 10/20/2012 4:05 AM, Ciaran McCreesh wrote:
>> On Sat, 20 Oct 2012 03:52:49 -0700
>> "Gregory M. Turner" <gmt@×××××.us> wrote:
>>> Took me a while, but I think I see why this is correct, now (mostly
>>> -- see below).  The source of my confusion was a mistaken assumption
>>> that die() would not respect PORTAGE_NONFATAL.
>>
>> The source of your confusion is more the impression that there is such
>> a thing as PORTAGE_NONFATAL. You should be reading the spec, not code.
>
> Seriously?  OK, let's try:
>
>   http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-13000012.3.3.1
>
> and
>
>   http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-13500012.3.3.6
>
> do not comport with the actual behavior of portage.
>
> Specifically, they very strongly suggest that nonfatal does not
> influence the behavior of die().  So depending on one's reading of the
> situation, either the PMS is misspecified or portage is broken.

I think portage's die should be fixed so that it dies regardless of the
nonfatal helper.

> Meanwhile,
>
>
> http://dev.gentoo.org/~zmedico/portage/doc/ch05s03s05.html#package-ebuild-eapi-4-helpers-die-nonfatal
>
>
> is dusting so much under the carpet that I can't possibly do my job as
> an eclass author without reverse-engineering, dry-run code analysis, or
> asking the SME's here on the mailing list how this is supposed to work
> in practice.
>
> I've already asked the mailing list and so far the closest thing I have
> to an answer is Zac's response.  Although I appreciate his help, I've
> explained why his response doesn't fully address my concerns.  If you
> don't trust my dry-run analysis then we can try the reverse-engineering
> approach.  Give this ebuild a try:
>
> ---->8----
> # Copyright 1999-2012 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=4
> DESCRIPTION="Foo"
> SLOT="0"
> KEYWORDS="~x86 ~amd64 ~x86-linux ~amd64-linux"
> IUSE=""
> DEPEND=""
> RDEPEND="${DEPEND}"
> utility_fn() { die "uhoh"; }
> src_unpack() { mkdir -p "${S}"; }
> src_prepare() { nonfatal utility_fn; }
> src_compile() { echo "yaaay" > foo.txt; }
> src_install() { dodoc foo.txt; }
> ----8<----
>
> As you can see, my dry-run analysis appears to have been correct.
>
> There is no documentation concerning best practices for eclass authors
> post-EAPI4, so I can't just RTFM -- there is no FM.  Furthermore, it
> appears that EAPI4 has broken a great many eclasses when invoked with
> the new nonfatal operator.  I guess I can just file a bug for that since
> so far nobody seems too concerned by it, but that still doesn't help me
> to write my eclass.

As far as I can tell, nonfatal was only intend ed to work with package
manager built-in helpers. I don't think it's a good idea to try and
extend it to eclass functions.
-- 
Thanks,
Zac