Gentoo Archives: gentoo-dev

From: David Leverton <levertond@××××××××××.com>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] EAPI 3 and "nonfatal die"
Date: Fri, 21 Aug 2009 20:58:22
Message-Id: 200908212156.42396.levertond@googlemail.com
1 In EAPI 3, most commands and functions provided by the package
2 manager automatically call die if they fail. There's also a
3 new "nonfatal" function that can be used to suppress this
4 behaviour: by prefixing a function/command call with nonfatal,
5 the automatic die behaviour is suppressed during the executation
6 of that function/command.
7
8 The difficulty here is that it's not clear what nonfatal should
9 do to explicit die and assert calls. On the one hand, if
10 nonfatal does suppress these functions, then nonfatal can be
11 usefully used with eclass functions - silly hypothetical example:
12
13 # eclass
14 escons() {
15 scons "${@}" || die "scons failed"
16 }
17
18 # ebuild
19 nonfatal escons || do_something_else
20
21 On the other hand, it could be risky to change the behaviour of
22 existing functions like that:
23
24 do_foo() {
25 cd foo || die "cd failed"
26 # something that would be dangerous if run in some other directory
27 }
28
29 If called as "nonfatal do_foo" and the cd failed, do_foo
30 /wouldn't/ return a failure code - it would proceed with the rest
31 of its body and wreak all manner of havoc.
32
33 One way around this would be to add either an option to die to
34 explicitly tell it to respect nonfatal, or an alternative die
35 function. This would allow eclasses to choose to respect
36 nonfatal when it's safe to do so, but without changing existing
37 behaviour. The disadvantage of this is that it would require
38 changes to all eclass functions that could potentially use it,
39 plus the slight ugliness of making them handle older EAPIs as
40 well.
41
42 Another option would be to make die respect nonfatal by default,
43 and add an option that doesn't. This wouldn't require changes to
44 eclasses that want the nonfatal behaviour, but it would require
45 some care to make sure that it was used when necessary. A
46 potential advantage of this over the previous solution is that if
47 the "force" option is implemented with an environment variable,
48 it can be used regardless of EAPI - the previous example could be
49 changed to something like
50
51 do_foo() {
52 cd foo || DIE_FORCE=1 die "cd failed"
53 # something that would be dangerous if run in some other directory
54 }
55
56 Does anyone have any opinions on which of the four options (#1
57 make die respect nonfatal, #2 make die always die, #3 add a new
58 die variant that respects nonfatal, #4 make regular die respect
59 nonfatal, and add a new variant that doesn't) we should go with?
60 We should definitely get this resolved and agreed on before EAPI
61 3 is finalised.

Replies

Subject Author
Re: [gentoo-dev] EAPI 3 and "nonfatal die" Maciej Mrozowski <reavertm@××××××.fm>
[gentoo-dev] Re: EAPI 3 and "nonfatal die" David Leverton <levertond@××××××××××.com>
Re: [gentoo-dev] EAPI 3 and "nonfatal die" Arfrever Frehtes Taifersar Arahesis <Arfrever@g.o>
[gentoo-dev] Re: EAPI 3 and "nonfatal die" Ryan Hill <dirtyepic@g.o>