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" <[email protected]> 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
