From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-37399-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1MebBm-0006x4-MQ
for garchives@archives.gentoo.org; Fri, 21 Aug 2009 20:58:22 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 6DA98E03A3;
Fri, 21 Aug 2009 20:58:21 +0000 (UTC)
Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218])
by pigeon.gentoo.org (Postfix) with ESMTP id 1E306E03A3
for <gentoo-dev@lists.gentoo.org>; Fri, 21 Aug 2009 20:58:21 +0000 (UTC)
Received: by ewy18 with SMTP id 18so1068264ewy.14
for <gentoo-dev@lists.gentoo.org>; Fri, 21 Aug 2009 13:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=gamma;
h=domainkey-signature:received:received:from:to:subject:date
:user-agent:mime-version:content-type:content-transfer-encoding
:content-disposition:message-id;
bh=tkdNRefMm+IhnCK39eO5kV971mPzP3JRoh+bJ6tVb0Y=;
b=qaXvb+skTXJQRjnk5eUj9414tKLjF2q53qQwHYOVp257KhiTY8MzGvqan0GQbn0lAO
Vl1UZ/ki1GVnnj3ipQpuGRE9erISqHKMgwzojZrU+No0ocnORLxZdVC7cBCKah9FrXdq
y70khpUqEwqy9mRJitGycymCgz5caYEbaILaY=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=googlemail.com; s=gamma;
h=from:to:subject:date:user-agent:mime-version:content-type
:content-transfer-encoding:content-disposition:message-id;
b=vJHm2Ly6UGNfXBOlJbouioz4V4ybmXLKiBHgX6zPCkKkSyH9eqJ1wGA1x3okxN4QZL
z8bYDLMNFH9GInci2q8WfU4gxZvyR/Q+N0/KBf5cgE9pVKojLMk5FGycuDJH6z1AVLu2
cDM3NxhhUpVR7rNB3shZmRUo19znv83l8PIME=
Received: by 10.210.66.10 with SMTP id o10mr1943382eba.95.1250888300602;
Fri, 21 Aug 2009 13:58:20 -0700 (PDT)
Received: from ?192.168.0.4? (5acc338e.bb.sky.com [90.204.51.142])
by mx.google.com with ESMTPS id 10sm1478765eyz.1.2009.08.21.13.58.19
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Fri, 21 Aug 2009 13:58:20 -0700 (PDT)
From: David Leverton <levertond@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] EAPI 3 and "nonfatal die"
Date: Fri, 21 Aug 2009 21:56:41 +0100
User-Agent: KMail/1.9.10
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200908212156.42396.levertond@googlemail.com>
X-Archives-Salt: 78ce3785-b7c2-428a-92b0-b094c9275cbd
X-Archives-Hash: 358b12a494173ab82f3e7d1b2b6b5bf9
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.