Welcome to Soft32 Linux Forums!
FAQFAQ    SearchSearch      ProfileProfile    Private MessagesPrivate Messages   Log inLog in

[gentoo-dev] EAPI 3 and "nonfatal die"

 
   Soft32 Home -> Linux -> Development RSS
Next:  Bug#542866: lintian: Check for PS and PDF files i..  
Author Message
David Leverton

External


Since: May 10, 2009
Posts: 6



(Msg. 1) Posted: Fri Aug 21, 2009 5:20 pm
Post subject: [gentoo-dev] EAPI 3 and "nonfatal die"
Archived from groups: linux>gentoo>dev (more info?)

In EAPI 3, most commands and functions provided by the package
manager automatically call die if they fail. There's also a
new "nonfatal" function that can be used to suppress this
behaviour: by prefixing a function/command call with nonfatal,
the automatic die behaviour is suppressed during the executation
of that function/command.

The difficulty here is that it's not clear what nonfatal should
do to explicit die and assert calls. On the one hand, if
nonfatal does suppress these functions, then nonfatal can be
usefully used with eclass functions - silly hypothetical example:

# eclass
escons() {
scons "${@}" || die "scons failed"
}

# ebuild
nonfatal escons || do_something_else

On the other hand, it could be risky to change the behaviour of
existing functions like that:

do_foo() {
cd foo || die "cd failed"
# something that would be dangerous if run in some other directory
}

If called as "nonfatal do_foo" and the cd failed, do_foo
/wouldn't/ return a failure code - it would proceed with the rest
of its body and wreak all manner of havoc.

One way around this would be to add either an option to die to
explicitly tell it to respect nonfatal, or an alternative die
function. This would allow eclasses to choose to respect
nonfatal when it's safe to do so, but without changing existing
behaviour. The disadvantage of this is that it would require
changes to all eclass functions that could potentially use it,
plus the slight ugliness of making them handle older EAPIs as
well.

Another option would be to make die respect nonfatal by default,
and add an option that doesn't. This wouldn't require changes to
eclasses that want the nonfatal behaviour, but it would require
some care to make sure that it was used when necessary. A
potential advantage of this over the previous solution is that if
the "force" option is implemented with an environment variable,
it can be used regardless of EAPI - the previous example could be
changed to something like

do_foo() {
cd foo || DIE_FORCE=1 die "cd failed"
# something that would be dangerous if run in some other directory
}

Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
We should definitely get this resolved and agreed on before EAPI
3 is finalised.
Back to top
Login to vote
David Leverton

External


Since: May 10, 2009
Posts: 6



(Msg. 2) Posted: Fri Aug 21, 2009 5:20 pm
Post subject: [gentoo-dev] Re: EAPI 3 and "nonfatal die" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Friday 21 August 2009 21:56:41 David Leverton wrote:
> A potential advantage of this over the previous solution is that if
> the "force" option is implemented with an environment variable,
> it can be used regardless of EAPI

....except that the previous solution could use an environment variable too, of
course.
Back to top
Login to vote
Zac Medico

External


Since: May 19, 2006
Posts: 96



(Msg. 3) Posted: Mon Aug 24, 2009 7:20 pm
Post subject: Re: [gentoo-dev] Re: EAPI 3 and "nonfatal die" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

Ryan Hill wrote:
> On Fri, 21 Aug 2009 21:56:41 +0100
> David Leverton <levertond.TakeThisOut@googlemail.com> wrote:
>
>> Does anyone have any opinions on which of the four options (#1
>> make die respect nonfatal, #2 make die always die, #3 add a new
>> die variant that respects nonfatal, #4 make regular die respect
>> nonfatal, and add a new variant that doesn't) we should go with?
>> We should definitely get this resolved and agreed on before EAPI
>> 3 is finalised.
>
> I'd like die to respect nonfatal. People using nonfatal should check
> beforehand that the functions they're calling won't do anything stupid if
> die's are ignored.

If you're doing that then it might be wise to add an 'assert' helper
that is guaranteed to generate an exception regardless of 'nonfatal'
status.
--
Thanks,
Zac
Back to top
Login to vote
"Marijn Schouten

External


Since: Mar 01, 2007
Posts: 37



(Msg. 4) Posted: Tue Aug 25, 2009 7:20 am
Post subject: Re: [gentoo-dev] Re: EAPI 3 and "nonfatal die" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Faulhammer wrote:
> Hi,
>
> Ryan Hill <dirtyepic.TakeThisOut@gentoo.org>:
>
>> On Fri, 21 Aug 2009 21:56:41 +0100
>> David Leverton <levertond.TakeThisOut@googlemail.com> wrote:
>>
>>> Does anyone have any opinions on which of the four options (#1
>>> make die respect nonfatal, #2 make die always die, #3 add a new
>>> die variant that respects nonfatal, #4 make regular die respect
>>> nonfatal, and add a new variant that doesn't) we should go with?
>>> We should definitely get this resolved and agreed on before EAPI
>>> 3 is finalised.
>> I'd like die to respect nonfatal. People using nonfatal should check
>> beforehand that the functions they're calling won't do anything
>> stupid if die's are ignored. If there's something that absolutely
>> has to die, nonfatal or not, then use a variable. I guess that's #4?
>
> I agree here (yes, I know, a "ME TOO" posting, but I say this as PMS
> team member).

I thought the whole idea was that functions that don't currently die by default
because sometimes this is unwanted will now die by default but provide an opt
out --non-fatal switch to get back the old behavior. In the non-fatal case such
functions should then again (as in the current situation) not call die.

Some functions will not have a --non-fatal switch.
Some functions should not have a --non-fatal switch.
Some functions will call die unconditionally.

What is the reason that we are trying to generalize non-fatal from a simple
switch to a full-blown primitive that should handle whatever it's thrown?

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqTuzoACgkQp/VmCx0OL2xh1ACgjvtPz+3uke5p2p+iVuSmGw1u
JKwAn2O2l1h8gRDkGnfZ2aIwaIHvlr/L
=ybPQ
-----END PGP SIGNATURE-----
Back to top
Login to vote
Display posts from previous:   
Related Topics:
[gentoo-dev] [RFC] EAPI - On the EAPI subject Brian just brought back, I had this idea that we could use the same approch XML took with HTML. Th...

[gentoo-dev] EAPI-1 (or >1, perhaps) Proposal: AND Depende.. - I occasionally run across a package version dependency issue that cannot be elegantly solved by the current dependency...

[gentoo-dev] [RFC] should we do an EAPI bump now with feat.. - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, Bug 174380 [1] has a growing list of features that may be....

[gentoo-dev] [Fwd: [gentoo-user] Calling all Gentoo people.. - To all Gentoo users/devs in or around Cambridge, UK: A couple of us on the forums have been thinking about a meet-up..

[Fwd: Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP .. - squalellmail really should have a feature where replying to a mailing list defaults to emailing the list, not the perso...

[gentoo-dev] [Fwd: [gentoo-security] Trojan for Gentoo, pa.. - perhaps some motivation for portage devs.... -------- Original Message -------- Subject: [gentoo-security] Trojan..
       Soft32 Home -> Linux -> Development All times are: Pacific Time (US & Canada) (change)
Page 1 of 1

 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Categories:
 Windows
  Linux
 Mac
 PDA


[ Contact us | Terms of Service/Privacy Policy ]