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

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

[David Leverton]

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.

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

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 1196 bytes --]

On Friday 21 of August 2009 22:56:41 David Leverton 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 suggest #5 - drop the idea of 'nonfatal'.

Quoting devmanual:
"The die function should be used to indicate a fatal error and abort the 
build. Its parameters should be the message to display."
Period.
In such case, following code:

nonfatal some_function

when:
some_function() {
  so_sth || die "sth failed"
}

only means, that "some_function" shouldn't have been equipped with 'die' 
mechanism, as use case appeared that demands it being non-fatal.
And in this case "some_function" should be fixed to be nonfatal instead (and 
all existing invocations suffixed by "|| die".
Simple as this.
Please refrain from adding silly workarounds like this - only thing they add 
is unnecessary complexity and thus maintenance/debugging burden.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

On Fri, 21 Aug 2009 23:09:33 +0200
Maciej Mrozowski <reavertm@poczta.fm> wrote:
> I suggest #5 - drop the idea of 'nonfatal'.

Then how do you plan to handle all the standard utilities that die on
failure in EAPI 3?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 3160 bytes --]

On Friday 21 of August 2009 23:12:23 Ciaran McCreesh wrote:
> On Fri, 21 Aug 2009 23:09:33 +0200

> Maciej Mrozowski <reavertm@poczta.fm> wrote:
> > I suggest #5 - drop the idea of 'nonfatal'.

> Then how do you plan to handle all the standard utilities that die on
> failure in EAPI 3?

>>> #1 make die respect nonfatal
The most obvious. About consequences - when you override behaviour of "die-on-
failure" function (that has been marked as fatal for reason) you're supposed 
to know what you're doing, so all codepaths should be checked in that case, 
otherwise one should be really ready to grab the pieces in such case.

>>> #2 make die always die
In such case nonfatal is useless as it's supposed to surpass "die-on-failure" 
EAPI3 functions, am I right?
Correct me if I'm wrong, bug there are just two ways to mark function 
invocation as 'failed':
- return nonzero value - soft way
- abort further execution of script, so call die function - hard way

In such case nonfatal works against its purpose (it cannot interfere in 
arbitrary function's flow control, and return value only affects this, so the 
only mean for it is to interfere in general-purpose-die-function).
This could be fixed by introducing 'even-more-fatal' way of aborting script 
execution, like function 'really-die-seriously-this-time' that ignores 
'nonfatal' :P (which leads us to #3 and #4).

>>> #3 add a new die variant that respects nonfatal
Seems the most reasonable to me, but should be introduced with caution (if at 
all). It's very old question how to approach flow control: whether to:
- maintain in using 'do_it_now_think_later' approach (exceptions' handling, 
nonfatal)
- 'do_it_now_think_now' (checking return values)
Ideally would be to have just one.
And if the goal is to implement exception-handling-like (actually catching and 
ignoring) approach in flow control for EAPI3 instead of relying on return 
value (|| die)  with runtime errors throwing (current 'die'), one would need 
not just one or two "die functions", but maybe whole family, with different 
fatality levels (for example controlled by environment variable, so that one 
could ignore those with level > 0 or could be more strict and only ignore 
those with level > 2, when 0 would be the most fatal, 1 less-lethal and so 
on).

>>> #4 make regular die respect nonfatal, and add a new variant that doesn't) 
we should go with?
All existing 'die' invocations now are supposed to be fatal (according to 
definition in devmanual), so making them maybe-fatal in EAPI3 is wrong imho.

General problem is defining what's really fatal and what's not - and I can 
assure that someone in a future will find some use case for preventing 
aborting of execution of some fatal function that failed.

That being said I don't like refraining from "return value approach" towards 
"exception handling approach" (and I'm ebuild/eclass developer and I don't see 
adding || die very disturbing) that has been proposed for EAPI3 in die-on-
failure utility functions, and thus I don't like nonfatal (which is of course 
needed for them).

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Sat, 22 Aug 2009 01:01:48 +0200
Maciej Mrozowski <reavertm@poczta.fm> wrote:
> That being said I don't like refraining from "return value approach"
> towards "exception handling approach"

nonfatal's not an exception handling approach. Think of it as a utility
like 'nice', 'ionice', 'xargs', 'env' or 'hilite'.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 849 bytes --]

On Saturday 22 of August 2009 01:06:30 Ciaran McCreesh wrote:
> On Sat, 22 Aug 2009 01:01:48 +0200
> 
> Maciej Mrozowski <reavertm@poczta.fm> wrote:
> > That being said I don't like refraining from "return value approach"
> > towards "exception handling approach"
> 
> nonfatal's not an exception handling approach. Think of it as a utility
> like 'nice', 'ionice', 'xargs', 'env' or 'hilite'.

Le sigh..
Replacing return value with die ("throw") *and* providing 'nonfatal' as 
mechanism to catch and ignore what's been thrown is obviously "exception 
handling approach" (not literally that is, I don't have to recall the 
semantics of \" character) - every respected software engineer will see that.

But on topic, if you want to participate in discussion, please refer to 
suggestions given by David, please.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Sat, 22 Aug 2009 01:20:36 +0200
Maciej Mrozowski <reavertm@poczta.fm> wrote:
> > > That being said I don't like refraining from "return value
> > > approach" towards "exception handling approach"
> > 
> > nonfatal's not an exception handling approach. Think of it as a
> > utility like 'nice', 'ionice', 'xargs', 'env' or 'hilite'.
> 
> Le sigh..
> Replacing return value with die ("throw") *and* providing 'nonfatal'
> as mechanism to catch and ignore what's been thrown is obviously
> "exception handling approach" (not literally that is, I don't have to
> recall the semantics of \" character) - every respected software
> engineer will see that.

That isn't what nonfatal does. It does not in any way catch and ignore
what's been thrown. It prevents the fatal notification from being sent
in the first place.

die is not a throw operation, never has been a throw operation (see the
whole "die in subshells" mess) and isn't going to be a throw operation.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[David Leverton]

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.

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1.1: Type: Text/Plain, Size: 3486 bytes --]

2009-08-21 22:56:41 David Leverton napisał(a):
> 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?

I think that 'DIE_FORCE=1 die "${die_message}"' (which was invented by me) would be the
best option. It will allow to use nonfatal() with eclass functions with the smallest
number of required changes in eclasses.

I would like to also notice that (not yet approved by Council) definition of nonfatal()
in PMS was recently drastically changed without proper discussion with developers of
other package managers. [1] was sent about 20 minutes after discussion about nonfatal()
started in #gentoo-portage in about 2009-08-06 19:45 UTC.
(I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).)
I think that such drastic changes should be first discussed on gentoo-dev mailing list.

[1] http://archives.gentoo.org/gentoo-pms/msg_5ae501394eaeff148cfc349f84d960c9.xml

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #1.2: channel_#gentoo%2dportage.freenode_2009-08-06.log --]
[-- Type: text/x-log, Size: 12334 bytes --]

### Log session started at 2009-08-06T13:57:20 ###
[13:57:20] Arfrever [n=Arfrever@gentoo/developer/arfrever] has joined #gentoo-portage
[13:57:20] Channel topic is: This is not a help/support channel || Ebuild dev questions go to #gentoo-dev-help and usage questions go to #gentoo || Portage resources: http://www.gentoo.org/proj/en/portage/index.xml#doc_chap6
[13:57:20] Topic was set by zmedico on 2009-06-07T06:54:17
[13:57:20] pratchett.freenode.net [*@*] has set channel mode +tnc
[13:57:20] Channel was created at 2006-11-26T07:42:44
[14:07:37] scarabeus [n=scarab@gentoo/developer/scarabeus] has quit IRC: "No Ping reply in 90 seconds."
[14:11:27] scarabeus [n=scarab@net-2-2.jaw.cz] has joined #gentoo-portage
[14:37:51] sping_ [n=sping@e179008226.adsl.alicedsl.de] has joined #gentoo-portage
[14:54:07] reavertm [n=reavertm@gentoo/contributor/reavertm] has quit IRC: Remote closed the connection
[15:05:30] few [n=few@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:05:34] few [n=few@gibbs.nat.uni-magdeburg.de] has quit IRC: Remote closed the connection
[15:05:50] few [n=few@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:06:05] few [n=few@gibbs.nat.uni-magdeburg.de] has quit IRC: Client Quit
[15:08:02] slonopotamus [n=slonopot@83.149.10.164] has quit IRC: Read error: 110 (Connection timed out)
[15:08:10] FuzzyRay [n=pvarner@gentoo/developer/FuzzyRay] has joined #gentoo-portage
[15:21:01] noisebleed [n=noiseble@piggy.inescn.pt] has quit IRC: Remote closed the connection
[15:41:22] sping_ [n=sping@gentoo/user/sping] is now known as sping_afk
[16:07:53] ali_bush [n=alistair@gentoo/developer/alibush] has quit IRC: Read error: 110 (Connection timed out)
[16:33:35] gargoyle-grin [n=randerso@gentoo/contributor/gargoyle-grin] has joined #gentoo-portage
[16:46:24] yugmix [n=yugmix@CEPci-02p14-94.ppp18.odn.ad.jp] has joined #gentoo-portage
[16:47:33] slonopotamus [n=slonopot@80.90.124.131] has joined #gentoo-portage
[17:07:45] neurogeek||m [n=neurogee@gentoo/developer/neurogeek] has joined #gentoo-portage
[17:29:25] Eudyptula [n=Eudyptul@pool-96-227-117-222.phlapa.east.verizon.net] has joined #gentoo-portage
[17:50:01] few [n=few@90.136.223.210] has joined #gentoo-portage
[18:08:32] noisebleed [n=noiseble@kermit.inescn.pt] has joined #gentoo-portage
[18:13:59] few [n=few@90.136.223.210] has quit IRC: Remote closed the connection
[18:57:05] noisebleed [n=noiseble@kermit.inescn.pt] has quit IRC: Remote closed the connection
[18:57:46] noisebleed [n=noiseble@piggy.inescn.pt] has joined #gentoo-portage
[19:03:45] neurogeek__ [n=neurogee@201.208.72.207] has joined #gentoo-portage
[19:04:47] neurogeek||m [n=neurogee@gentoo/developer/neurogeek] has quit IRC: Nick collision from services.
[19:05:15] neurogeek__ [n=neurogee@201.208.72.207] is now known as neurogeek||m
[19:13:16] igli [n=igli@fu/coder/igli] has joined #gentoo-portage
[19:21:30] javaJake [n=javaJake@unaffiliated/javajake] has joined #gentoo-portage
[20:50:53] noisebleed [n=noiseble@piggy.inescn.pt] has quit IRC: Remote closed the connection
[20:56:28] slonopotamus [n=slonopot@80.90.124.131] has quit IRC: Remote closed the connection
[20:56:39] slonopotamus [n=slonopot@80.90.124.131] has joined #gentoo-portage
[21:12:07] ali_bush [n=alistair@gentoo/developer/alibush] has joined #gentoo-portage
[21:35:17] few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-portage
[21:43:36] Gef` [n=Gef`@abo-76-63-68.mts.modulonet.fr] has joined #gentoo-portage
[21:46:16] <Arfrever> zmedico: I have 2 questions about nonfatal().
[21:46:16] <Arfrever> In ebuilds using EAPI <3, should nonfatal() be not defined, or should it be defined and call e.g. 'die "nonfatal not supported in this EAPI"'?
[21:46:16] <Arfrever> In ebuilds using EAPI >=3, when 'nonfatal ${command}' is called and ${command} fails, should it be silent, or should ewarn be used to print a warning?
[21:46:49] <zmedico> nonfatal should die in <3
[21:47:41] <zmedico> if nonfatal fails, I think it should warn on stderr, but not ewarn
[21:47:51] <zmedico> that way they can send it to /dev/null
[21:47:57] <zmedico> and it won't be logged
[21:48:45] <zmedico> maybe pms says something about that?
[21:53:01] <Arfrever> zmedico: PMS only says about non-zero exit status...
[21:53:22] <zmedico> ok, stderr warning seems good to me
[21:53:27] <zmedico> that's pretty standard
[21:53:45] <chithead> what happens if one puts "nonfatal die"? ;)
[21:53:58] <Arfrever> chithead: Warning.
[22:01:52] <dleverton> Arfrever: the intention was that nonfatal wouldn't apply to die itself, only builtin commands that might call die when they fail
[22:03:35] <Arfrever> dleverton: IMHO e.g. `nonfatal econf` should work :) .
[22:03:44] <chithead> dleverton: so "nonfatal die" would die, but "nonfatal nonfatal die" would not?
[22:04:04] <dleverton> Arfrever: right, that would just return an error status if econf fails
[22:04:26] <dleverton> chithead: no, because "nonfatal die" calls die regardless of whether it fails or not :-P
[22:06:04] <Arfrever> dleverton: PMS is unprecise, so we can implement nonfatal() however we want :) .
[22:06:59] <igli> ugh that is such a nasty syntax
[22:07:02] igli hides
[22:07:29] <dleverton> Arfrever: for one thing it's about to be changed to clarify that, for another thing, if you notice something like that it's better to get it clarified than to allow obvious potential incompatibilities to sneak in
[22:08:08] <dleverton> igli doesn't like HOFs :-(
[22:09:43] <dleverton> But in any case, thanks Arfrever and chithead for uncovering that
[22:14:46] <Arfrever> dleverton: `nonfatal ${function_from_eclass}` should work without modifying all functions defined in eclasses.
[22:15:47] <dleverton> Possibly
[22:16:11] <dleverton> Feel free to mention that on the gentoo-pms@ thread if you think it's a strong enough case for changing it
[22:16:28] <Arfrever> dleverton: PMS doesn't disallow it from working.
[22:16:44] <Arfrever> dleverton: My implementation of nonfatal() will support it.
[22:16:49] <dleverton> It will soon, if you don't argue against it
[22:17:02] <ABCD> what is `nonfatal foo` supposed to do if foo is defined as `foo() { (( $# == 1 )) || die "need 1 argument"; .... }`?
[22:17:32] <Arfrever> dleverton: You cannot drastically change behavior of functions defined in PMS without council decision.
[22:17:50] <igli> doFoo --or-die "${foo[@]}"
[22:18:05] <dleverton> It's not a "drastic change", it's removing an accidental ambiguity
[22:18:36] <chithead> oh my, what have I started :)
[22:18:44] <dleverton> You could also argue that you can't apply your own interpretation of PMS without council decision
[22:19:13] <dleverton> chithead: it's better this way than if we'd only noticed when half the tree was relying on one or the other version ;-)
[22:19:58] <dleverton> But again, if you have strong feelings, it's best to get it discussed and agreed before people start using it
[22:20:13] <Arfrever> dleverton: There is no agreement that the ambiguity should be removed in a way suggested by you.
[22:20:47] <dleverton> Well, that's why patches get sent to the list for comments before being pushed
[22:22:08] <ABCD> I haven't read PMS recently, but does it allow for a function called under nonfatal to know that it was called under nonfatal?
[22:22:22] <ABCD> (if not, I think it probably should)
[22:22:54] <Arfrever> ABCD: It doesn't disallow it.
[22:23:02] <igli> a lib function could check it, but it's a pita for no reason imo.
[22:23:41] <ABCD> how would that function find out without 1) calling "die", or 2) violating PMS?
[22:24:01] <ABCD> (assume this is an eclass function, for instance)
[22:24:06] <dleverton> Arfrever: it doesn't disallow the package manager from running rm -rf / at random points, either
[22:24:58] <igli> man bash /FUNCNAME
[22:26:57] <ABCD> igli: that wasn't exactly what I had in mind (plus, "nonfatal" possibly could be implemented as an alias, which would cause that not to work)
[22:29:56] <igli> nonfatal is an alias? interesting
[22:30:05] <igli> Gentoo bash is hilarious
[22:30:08] igli [n=igli@fu/coder/igli] has left #gentoo-portage: "Have a good one ;-)"
[22:31:37] <dleverton> I'll never understand that guy
[22:31:39] Naib [n=j@fu/hw/naib] has joined #gentoo-portage
[22:36:53] <zmedico> ABCD: an alias is ok if it's only allowed in src_* phases. otherwise the expansion in environment.bz2 could cause problems depending on which package manager is used.
[22:39:00] <ABCD> zmedico: I was only refering to possibilities (as in, that which PMS does not explicitly prohibit, could be used by an implementation, no matter how hard that makes everyone else life :) )
[22:39:00] <Arfrever> zmedico: I almost implemented it (as function in isolated-functions.sh).
[22:39:27] <Arfrever> zmedico: How should the failure message be formatted?
[22:40:13] <zmedico> Arfrever: idk, just do it however you like and we can always change it
[22:51:09] slonopotamus [n=slonopot@80.90.124.131] has quit IRC: "Leaving"
[22:51:24] <Arfrever> zmedico: Committed in r13936.
[22:51:34] <zmedico> great, thank you
[23:01:11] <Tommy[D]> zmedico: could it be that the dependency calculation for already installed packages is somewhat borked? i told portage to "emerge -e world", got around 15 failed, but after that, still many left at "emerge -pvuDN world"
[23:01:55] <zmedico> Tommy[D]: they'd probably be removed by --depclean
[23:02:05] <zmedico> which is normal
[23:02:39] <Tommy[D]> zmedico: no, for example, the comple font set, which i had installed was not remerged (with a changed useflag)
[23:02:49] <Tommy[D]> *complete
[23:04:08] <zmedico> Tommy[D]: sounds like bug 280394 but I'm not aware of any change that would cause it
[23:04:10] <Willikins> zmedico: https://bugs.gentoo.org/280394 "sys-apps/portage-2.2_rc35 fails to update @system @world - packages to be updated are not found/updated - leaves packages out-dated!"; Gentoo Linux, Core system; NEW; tormen@gmx.net:dev-portage@g.o
[23:04:39] <zmedico> best thing is to do emerge -puvDN world --debug
[23:05:04] <zmedico> and try to find a specific package that should have been pulled in but wasn't
[23:05:11] <Tommy[D]> zmedico: it happens both to emerge -e and emerge -avuDN, in both cases, the ebuilds are shown in the depgraph, but somewhere during run are dropped
[23:06:49] <zmedico> hmm, it's just the reinstalls?
[23:07:44] <Tommy[D]> thats what i currently test since i want to try all installed packages with lib32 useflag
[23:09:16] <zmedico> weird. I'll see if I can reproduce it when I do my updates.
[23:09:32] <zmedico> maybe it's something in your patch
[23:11:25] <Tommy[D]> i currently reduce the list by updating by hand, once the list is smaller, i can look when those dropping is done
[23:13:30] jlec1 [n=jlec@ip-62-143-31-170.unitymediagroup.de] has joined #gentoo-portage
[23:13:51] <jlec1> zmedico: is this a portage unicode bug? bug 280600
[23:13:53] <Willikins> jlec1: https://bugs.gentoo.org/280600 "sys-libs/db creates localized strings in /usr/include/db.h; this prevents emerging python-3.1"; Gentoo Linux, Core system; NEW; olekhov@butovo.com:bug-wranglers@g.o
[23:14:13] <jlec1> I don't know who I wrangle it to.
[23:14:22] <jlec1> +should
[23:15:23] <Arfrever> jlec1: It's a duplicate of bug #280001.
[23:15:26] <Willikins> Arfrever: https://bugs.gentoo.org/280001 "dev-lang/python-3.1 fails to build with sys-libs/db headers containing non-UTF-8 characters"; Gentoo Linux, Unspecified; RESO, FIXE; amd@store20.com:python@g.o
[23:15:47] <Arfrever> jlec1: But you can assign this bug to sys-libs/db maintainers.
[23:15:58] <Arfrever> s/this/this new/
[23:17:06] <jlec1> Will do so
[23:19:06] <javaJake> Arfrever: how do you find those dups?
[23:19:21] <Arfrever> javaJake: I fixed the original bug.
[23:19:27] <javaJake> Ah :)
[23:21:45] <Tommy[D]> zmedico: maybe a problem with resuming? i just started a bigger list of packages, then after the first compile error it found nothing to resume and stopped
[23:24:24] <Arfrever> zmedico: FYI: A=1 true ; echo $A
[23:24:26] <Arfrever> :)
[23:31:24] <zmedico> Tommy[D]: hmm, maybe so. there was a change in the resume code
[23:33:03] <zmedico> --resume still seems to work here though
[23:44:46] Gef` [n=Gef`@abo-76-63-68.mts.modulonet.fr] has quit IRC: Client Quit
### Log session terminated at 2009-08-07T00:00:00 ###

[-- Attachment #1.3: channel_#gentoo%2dportage.freenode_2009-08-21.log --]
[-- Type: text/x-log, Size: 30009 bytes --]

### Log session started at 2009-08-21T00:00:00 ###
[00:01:30] <zmedico> Arfrever: pong
[00:14:01] ABCD [n=ABCD@gentoo/contributor/abcd] has quit IRC: Read error: 104 (Connection reset by peer)
[00:14:15] ABCD [n=ABCD@gentoo/contributor/abcd] has joined #gentoo-portage
[00:21:11] <Arfrever> zmedico: Can I commit http://dpaste.com/83369/ ?
[00:23:22] <dleverton> Arfrever: unless you do so with the aid of your time machine, that's not going to convince anyone who didn't already agree with you
[00:25:06] <Arfrever> dleverton: I know that nothing will convince Ciaran etc.
[00:25:51] <dleverton> The most you can say after commiting that is that it's been intentional, documented behaviour as of 2009-08-20, and therefore it can be added to PMS for the next EAPI bump
[00:26:28] <Arfrever> dleverton: It was always intentional, but it was accidentally undocumented.
[00:27:36] <Arfrever> Today is 2009-08-21 :) .
[00:28:22] dma` [n=dma@cpe-069-132-191-004.carolina.res.rr.com] has quit IRC: Read error: 110 (Connection timed out)
[00:28:50] <zmedico> Arfrever: looks good, thanks
[00:29:00] <Arfrever> zmedico: Thanks :) .
[00:31:20] mpagano [n=mpagano@gentoo/developer/mpagano] has quit IRC: "KVIrc Insomnia 4.0.0, revision: 3412, sources date: 20090703, built on: 2009/08/17 01:52:28 UTC http://www.kvirc.net/"
[00:32:33] <dleverton> The commit messages was "add an option to grab* so that if they're given a directory they'll recursively find all files in it and treat them like one big file. Also make use
[00:32:37] <dleverton> of this option for most of the config files."
[00:32:57] <dleverton> Doesn't sound like it was intentional to allow it in the tree to me
[00:33:00] <idl0r> zmedico: wrt VER_REGEX, any ideas how to use it in C? :) http://dpaste.com/83378/
[00:33:03] <dleverton> But of course, you already know that
[00:33:19] <idl0r> the example there doesn't match anything :(
[00:34:12] igli chuckles
[00:36:24] <zmedico> idl0r: I don't know, maybe there's some info in regex.h that will help you figure it out
[00:37:16] <zmedico>  /usr/include/regex.h
[00:37:32] <zmedico> says [:digit:] is supported
[00:38:11] <zmedico> idl0r: maybe you need some extra square brackets, like http://en.wikipedia.org/wiki/Special:Search?go=Go&search=:digit:
[00:38:34] <zmedico> I didn't type that link
[00:38:45] <zmedico> I guess my irc client expanded it
[00:38:54] <zmedico> http://en.wikipedia.org/wiki/Special:Search?go=Go&search=:digit:
[00:39:00] <zmedico> funky
[00:39:20] <zmedico> anyway, that's [:digit:]
[00:39:32] <zmedico> with two sets of [] brackets
[00:43:27] <idl0r> ah, thats it
[00:43:29] <idl0r> ty :)
[00:43:47] <zmedico> cool
[00:44:29] <idl0r> so: "^(cvs\\.)?([[:digit:]]+)((\\.[[:digit:]]+)*)([a-z]?)((_(pre|p|beta|alpha|rc)[[:digit:]]*)*)(-r([[:digit:]]+))?$"
[00:48:03] djanderson [n=djanders@hltncable.pioneerbroadband.net] has quit IRC: Read error: 110 (Connection timed out)
[00:51:13] <javaJake> Egad, what's that for?
[00:51:25] <javaJake> If you don't mind me asking
[00:51:51] <igli> (-r([[:digit:].]+)) # for prefix, so long as you're checking it
[00:52:23] <igli> (you have to check stuff in any event, ime)
[00:53:09] <igli> javaJake: match a CPV with one system call ;)
[00:53:22] <javaJake> Nice
[00:53:24] javaJake grabs
[00:53:24] <igli> well a few, but in general one.
[00:53:55] <igli> s/cvs/vcs ;)
[00:54:23] <igli> damn that's just version
[00:54:26] <igli> you can do whole CPV
[00:55:26] <igli> declare -r CPV='^((.*-.*)|virtual)/(.*)-(cvs\.)?([0-9]+)((\.[0-9]+)*)([a-z]?)((_(pre|p|beta|alpha|rc)[0-9]*)*)(-r([0-9.]+))?$'
[00:59:09] dma` [n=dma@cpe-069-132-191-004.carolina.res.rr.com] has joined #gentoo-portage
[01:11:56] <javaJake> From an ebuild, how do I detect whether or not I'm running on an OSX system?
[01:12:11] <javaJake> I'm running on a prefix'ed system, if that matters. (Shouldn't. :)
[01:13:19] <zmedico> javaJake: use kernel_Darwin
[01:14:12] <javaJake> ...which is not set on my system.
[01:14:17] <javaJake> Prefix must matter, then :/
[01:15:12] <zmedico> what is KERNEL set to?
[01:15:31] <zmedico> that should USE_EXPAND to kernel_$KERNEL
[01:15:43] <javaJake> Not set
[01:15:52] <javaJake> According to emerge --info and env
[01:16:03] <zmedico> you're looking in the wrong place
[01:16:11] <zmedico> try `portageq envvar KERNEL`
[01:16:18] <zmedico> it should be set in the profile
[01:16:26] <javaJake> Darwin :)
[01:16:32] <zmedico> cool
[01:29:17] gargoyle-grin [n=randerso@gentoo/contributor/gargoyle-grin] has quit IRC: "Leaving."
[01:30:32] <Arfrever> Calchan: Nothing needs to be reverted.
[02:13:48] ferringb_ [n=ferringb@c-24-130-139-50.hsd1.ca.comcast.net] has joined #gentoo-portage
[02:18:47] Obeliks [i=obeliks@gentoo/contributor/Obeliks] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:47] chithead [n=chithanh@gentoo/user/chithead] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] mitsutaka [n=mitsutak@ns1.miraclelinux.com] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] jmbsvicetto [i=jmbsvice@gentoo/developer/jmbsvicetto] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] Willikins [i=nobody@gentoo/bot/Willikins] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] spb [i=stephen@freenode/developer/exherbo.spb] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:49] r0bertz [n=zhangle@gentoo/developer/r0bertz] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:50] krushia [n=krushia@pool-71-168-96-174.cncdnh.east.myfairpoint.net] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:18:50] tanderson [n=gentoofa@gentoo/developer/gentoofan23] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[02:19:53] jmbsvicetto [i=jmbsvice@gentoo/developer/jmbsvicetto] has joined #gentoo-portage
[02:19:53] Willikins [i=nobody@gentoo/bot/Willikins] has joined #gentoo-portage
[02:19:53] spb [i=stephen@freenode/developer/exherbo.spb] has joined #gentoo-portage
[02:19:53] r0bertz [n=zhangle@gentoo/developer/r0bertz] has joined #gentoo-portage
[02:19:53] krushia [n=krushia@pool-71-168-96-174.cncdnh.east.myfairpoint.net] has joined #gentoo-portage
[02:19:53] tanderson [n=gentoofa@gentoo/developer/gentoofan23] has joined #gentoo-portage
[02:25:29] ferringb [n=ferringb@c-24-130-139-50.hsd1.ca.comcast.net] has quit IRC: Nick collision from services.
[02:25:30] ferringb_ [n=ferringb@c-24-130-139-50.hsd1.ca.comcast.net] is now known as ferringb
[02:40:58] mitsutaka [n=mitsutak@ns1.miraclelinux.com] has joined #gentoo-portage
[02:41:21] mitsutaka [n=mitsutak@ns1.miraclelinux.com] has quit IRC: Remote closed the connection
[02:42:43] mpagano [n=mpagano@gentoo/developer/mpagano] has joined #gentoo-portage
[03:33:24] mpagano [n=mpagano@gentoo/developer/mpagano] has quit IRC: "cya"
[04:46:44] reavertm_ [n=reavertm@bdl237.neoplus.adsl.tpnet.pl] has joined #gentoo-portage
[04:49:20] reavertm [n=reavertm@gentoo/contributor/reavertm] has quit IRC: Read error: 60 (Operation timed out)
[04:50:12] mitsutaka [n=mitsutak@ns1.miraclelinux.com] has joined #gentoo-portage
[04:50:12] Obeliks [i=obeliks@who.knows.what.possessed.us] has joined #gentoo-portage
[04:50:12] chithead [n=chithanh@gentoo/user/chithead] has joined #gentoo-portage
[04:54:52] zong_sharo [n=weechat@92.53.109.174] has quit IRC: "WeeChat 0.2.6.2"
[05:05:12] zong_sharo [n=weechat@92.53.109.174] has joined #gentoo-portage
[05:14:34] javaJake [n=javaJake@unaffiliated/javajake] has quit IRC: "night"
[05:14:52] smorg [n=quassel@97-116-4-14.mpls.qwest.net] has quit IRC: Remote closed the connection
[05:23:39] djanderson [n=djanders@hltncable.pioneerbroadband.net] has joined #gentoo-portage
[05:52:02] |t4bz| [n=Trevor@ppp121-45-169-216.lns11.adl2.internode.on.net] has joined #gentoo-portage
[06:13:48] t4bz [n=Trevor@ppp121-45-39-202.lns10.adl2.internode.on.net] has quit IRC: Read error: 101 (Network is unreachable)
[06:14:40] igli [n=igli@fu/coder/igli] has quit IRC: Remote closed the connection
[06:33:57] reavertm_ [n=reavertm@bdl237.neoplus.adsl.tpnet.pl] has quit IRC: Remote closed the connection
[06:44:58] djanderson [n=djanders@hltncable.pioneerbroadband.net] has quit IRC: Client Quit
[07:17:31] slonopotamus [n=slonopot@83.149.10.180] has joined #gentoo-portage
[07:40:54] few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-portage
[08:22:17] slonopotamus_ [n=slonopot@83.149.9.36] has joined #gentoo-portage
[08:30:51] Masa [n=sfmasasf@12.186.21.238] has joined #gentoo-portage
[08:31:23] Masa [n=sfmasasf@12.186.21.238] has left #gentoo-portage: "Leaving"
[08:40:35] slonopotamus [n=slonopot@83.149.10.180] has quit IRC: Read error: 110 (Connection timed out)
[08:58:38] rafaelmartins [n=rafael@unaffiliated/rafaelmartins/x-162351] has quit IRC: Remote closed the connection
[09:08:10] wired_ [n=wired@musici.static.otenet.gr] has joined #gentoo-portage
[09:45:41] wired_ [n=wired@gentoo/developer/wired] is now known as wired
[09:52:04] wired [n=wired@gentoo/developer/wired] has quit IRC: "ZNC - http://znc.sourceforge.net"
[09:57:04] slonopotamus_ [n=slonopot@83.149.9.36] has quit IRC: Connection timed out
[09:57:15] wired_ [n=wired@musici.static.otenet.gr] has joined #gentoo-portage
[10:04:20] wired_ [n=wired@gentoo/developer/wired] is now known as wired
[10:06:38] wired [n=wired@gentoo/developer/wired] has quit IRC: "ZNC - http://znc.sourceforge.net"
[10:07:11] wired_ [n=wired@gentoo/developer/wired] has joined #gentoo-portage
[10:11:39] wired_ [n=wired@gentoo/developer/wired] is now known as wired
[10:24:56] Tommy[D] [i=bnc@gateway/gpg-tor/key-0x35899067] has joined #gentoo-portage
[11:55:05] hkBst [n=hkBst@gentoo/developer/hkbst] has joined #gentoo-portage
[12:36:15] smorg [n=quassel@97-116-4-14.mpls.qwest.net] has joined #gentoo-portage
[13:17:46] scarabeus [n=scarab@gentoo/developer/scarabeus] has quit IRC: "No Ping reply in 90 seconds."
[13:18:20] scarabeus [n=scarab@gentoo/developer/scarabeus] has joined #gentoo-portage
[14:38:55] reavertm [n=reavertm@bdl237.neoplus.adsl.tpnet.pl] has joined #gentoo-portage
[15:34:53] slonopotamus [n=slonopot@83.149.10.134] has joined #gentoo-portage
[15:38:06] few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has quit IRC: Read error: 110 (Connection timed out)
[15:56:07] PSYCHO___ [n=scarab@gentoo/developer/scarabeus] has joined #gentoo-portage
[16:08:25] scarabeus [n=scarab@gentoo/developer/scarabeus] has quit IRC: Read error: 110 (Connection timed out)
[16:09:13] PSYCHO___ [n=scarab@gentoo/developer/scarabeus] is now known as scarabeus
[16:11:15] few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-portage
[16:38:43] gargoyle-grin [n=randerso@gentoo/contributor/gargoyle-grin] has joined #gentoo-portage
[17:04:09] CCIEChad|Away [i=CCIEChad@ip72-209-20-27.ri.ri.cox.net] has joined #gentoo-portage
[17:05:32] CCIEChad [i=CCIEChad@gentoo/contributor/cciechad] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] mpagano_ [n=mike@gentoo/developer/mpagano] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] peper [n=peper@gentoo/developer/paludis.lackey.peper] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] sungami [n=sungami@unaffiliated/sungami] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] alip [i=alip@unaffiliated/alip] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] keytoaster [n=tobias@gentoo/developer/keytoaster] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:05:33] puggy [n=puggy@ngsrvm01.ediamond.ox.ac.uk] has quit IRC: NETSPLIT calvino.freenode.net irc.freenode.net
[17:06:02] keytoaster [n=tobias@gentoo/developer/keytoaster] has joined #gentoo-portage
[17:06:02] alip [i=alip@unaffiliated/alip] has joined #gentoo-portage
[17:06:02] sungami [n=sungami@unaffiliated/sungami] has joined #gentoo-portage
[17:06:02] puggy [n=puggy@ngsrvm01.ediamond.ox.ac.uk] has joined #gentoo-portage
[17:06:02] mpagano_ [n=mike@gentoo/developer/mpagano] has joined #gentoo-portage
[17:06:11] sungami [n=sungami@unaffiliated/sungami] has quit IRC: Read error: 104 (Connection reset by peer)
[17:06:11] sungami [n=sungami@cpc1-cbly4-0-0-cust824.glfd.cable.ntl.com] has joined #gentoo-portage
[17:06:24] keytoaster [n=tobias@gentoo/developer/keytoaster] has quit IRC: SendQ exceeded
[17:06:50] peper [n=peper@gentoo/developer/paludis.lackey.peper] has joined #gentoo-portage
[17:07:06] sping_ [n=sping@e179002115.adsl.alicedsl.de] has joined #gentoo-portage
[17:07:39] keytoaster [n=tobias@gentoo/developer/keytoaster] has joined #gentoo-portage
[17:10:14] slonopotamus [n=slonopot@83.149.10.134] has quit IRC: "Leaving"
[17:10:37] ABCD_ [n=ABCD@gentoo/contributor/abcd] has joined #gentoo-portage
[17:11:52] sungami_ [n=sungami@cpc1-cbly4-0-0-cust824.glfd.cable.ntl.com] has joined #gentoo-portage
[17:12:13] Sput [n=sputnick@quassel/developer/sput] has quit IRC: Broken pipe
[17:12:33] <reavertm> Arfrever: you added 'file or dirs' in manual section of /etc/make.profile - is the right place?
[17:12:35] sungami [n=sungami@unaffiliated/sungami] has quit IRC: Read error: 104 (Connection reset by peer)
[17:12:57] Sput [n=sputnick@quassel/developer/sput] has joined #gentoo-portage
[17:14:10] <reavertm> (portage manual in svn)
[17:27:43] ABCD [n=ABCD@gentoo/contributor/abcd] has quit IRC: Success
[17:34:55] mitsutaka [n=mitsutak@ns1.miraclelinux.com] has quit IRC: Read error: 113 (No route to host)
[17:46:09] kallamej [n=kallamej@gentoo/developer/kallamej] has quit IRC: "brb"
[18:11:02] sping_ [n=sping@gentoo/user/sping] has quit IRC: Remote closed the connection
[18:11:34] r0bertz [n=zhangle@gentoo/developer/r0bertz] has quit IRC: Read error: 131 (Connection reset by peer)
[18:13:02] <Arfrever> reavertm: The /etc/make.profile/ section describes files supported in directories of profiles.
[18:13:13] r0bertz [n=zhangle@gentoo/developer/r0bertz] has joined #gentoo-portage
[18:15:47] <Arfrever> reavertm: /etc/make.profile is usually a symlink to appropriate profile in ${PORTDIR}/profiles.
[18:17:42] <Tommy[D]> Arfrever: it can also be a dir containing a parents file ;)
[18:19:46] mitsutaka [n=mitsutak@ns1.miraclelinux.com] has joined #gentoo-portage
[18:22:11] dma` [n=dma@cpe-069-132-191-004.carolina.res.rr.com] has quit IRC: Read error: 60 (Operation timed out)
[18:28:02] AmazingPudding [i=dreeevil@gentoo/developer/bonsaikitten] is now known as DrEeevil
[18:32:02] <reavertm> I'd rather add explicit info for manual entry regarding every package.* or use.* (wherever it really applies) in profile and  /etc/portage sections
[18:32:22] <reavertm> just to avoid confusion what's 'file or dir' and what's not
[18:45:55] scarabeus [n=scarab@gentoo/developer/scarabeus] has quit IRC: Remote closed the connection
[18:46:04] pva [n=pva@gentoo/developer/pva] has joined #gentoo-portage
[18:52:42] scarabeus [n=scarab@gentoo/developer/scarabeus] has joined #gentoo-portage
[19:09:42] sping_ [n=sping@gentoo/user/sping] has joined #gentoo-portage
[19:26:18] few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has quit IRC: "Verlassend"
[19:33:30] slonopotamus [n=slonopot@80.90.124.131] has joined #gentoo-portage
[19:44:01] <darkside_> Arfrever: concerning your recent commit. can you please modify it like so: http://dpaste.com/83664/ ?
[19:54:38] <Arfrever> darkside_: Yes.
[19:56:05] <reavertm> http://dpaste.com/83668/ - stable portage segfaulted here (during rebuilding of some random kde package), strange...
[19:56:22] <reavertm> sorry, it's 2.2_rc38, not stable (but stable python)
[20:00:44] <Arfrever> darkside_: r14116.
[20:02:41] <darkside_> ty
[20:12:22] rafaelmartins [n=rafael@unaffiliated/rafaelmartins/x-162351] has joined #gentoo-portage
[20:14:38] sungami_ [n=sungami@unaffiliated/sungami] has quit IRC: Read error: 104 (Connection reset by peer)
[20:15:43] sungami [n=sungami@cpc1-cbly4-0-0-cust824.glfd.cable.ntl.com] has joined #gentoo-portage
[20:33:05] Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] has joined #gentoo-portage
[20:59:39] CCIEChad|Away [i=CCIEChad@gentoo/contributor/cciechad] has quit IRC: Read error: 104 (Connection reset by peer)
[21:00:49] CCIEChad [i=CCIEChad@ip72-209-20-27.ri.ri.cox.net] has joined #gentoo-portage
[21:06:54] <CCIEChad> does anyone know when the next rc release of 2.2 is expected?
[21:08:21] <Arfrever> CCIEChad: Maybe zmedico :) .
[21:11:00] <CCIEChad> just curious I'm using SVN on my dev machine and the improvement in the handling of error messages and dep handling on svn are amazing. I have converted some windows users to gentoo who run ~portage but I didn't want to have to get them on SVN portage
[21:13:00] <CCIEChad> you guys have been doing great work I haven't tested but I swear it even seems faster
[21:24:35] slonopotamus [n=slonopot@80.90.124.131] has quit IRC: "Leaving"
[21:34:45] slonopotamus [n=slonopot@80.90.124.131] has joined #gentoo-portage
[21:34:51] <zmedico> CCIEChad: I'm releaseing 2.2_rc39 today
[21:35:28] <CCIEChad> zmedico: great thank you man
[21:35:40] <zmedico> you're welcome
[21:40:22] <tanderson> zmedico: ooh, does that have the controversial patch in it?
[21:41:05] <Arfrever> tanderson: It's not controversial for majority of people.
[21:41:23] <tanderson> Arfrever: having a majority doesn't make it controversial.
[21:41:31] <tanderson> Arfrever: is it in there is my question.
[21:41:46] <tanderson> besides, we don't know how many people feel one way or the other about it
[21:42:39] <reavertm> what's controversial?updating manual?
[21:43:05] <Arfrever> tanderson: Many people would object to reverting this change, so it probably won't be reverted (at least soon).
[21:43:13] <tanderson> reavertm: updating the portage docs.
[21:44:08] <tanderson> Arfrever: sure. Portage can support that and it's documentation should be accurate to what it does.
[21:44:35] <Arfrever> And now documentation is more accurate than it was earlier.
[21:44:49] <tanderson> But we shouldn't be modifying pms to every portage change because we need a little procedure or EAPI is useless
[21:44:55] <tanderson> zmedico: can I query btw?
[21:44:59] <zmedico> tanderson: I was planning to add a note saying that it's not part of the PMS spec
[21:45:05] <tanderson> zmedico: ok
[21:45:32] <zmedico> tanderson: yeah, query is fine any time
[21:46:36] <Arfrever> tanderson: This feature started to exist before EAPI=0 was introduced. PMS developers haven't included this feature in PMS due to accidental lack of mentioning this feature in Portage documentation.
[21:49:47] <Arfrever> tanderson: AFAIK documentation of EAPI=0 has been already changed after Council approved EAPI=0.
[21:50:31] <dleverton> Arfrever: my reading of the logs says that it was introduced a couple of months after EAPI 0, but that's not the main point
[21:50:47] tanderson [n=gentoofa@gentoo/developer/gentoofan23] has quit IRC: "Lost terminal"
[21:51:05] gentoofan23 [n=gentoofa@gentoo/developer/gentoofan23] has joined #gentoo-portage
[21:51:13] <dleverton> The spec has been mostly-approved, so while it's not completely frozen, it seems unfair to make changes like this that would badly break existing code that was written to the spec
[21:51:30] gentoofan23 [n=gentoofa@gentoo/developer/gentoofan23] is now known as tanderson
[21:51:49] <dleverton> Even assuming the omission from the docs originally was purely an accident, people have still written code based on what was actually documented
[21:52:17] <zmedico> it's the community's decision
[21:52:34] <zmedico> if the consensus is that it's worth changing, then it's changing
[21:52:38] <zmedico> if not, it's not
[21:52:42] <zmedico> that simple :)
[21:53:10] <jmbsvicetto> dleverton: one point that is worthy to consider (and please don't take it as any kind of attack to PMS) is that there has yet to be a final approval by the Council of the doc - at least as far as I can remember
[21:53:12] <reavertm> features adoption should be through controlled process (PMS), but in this case I thing it's beneficial to push through
[21:54:28] <Arfrever> dleverton: As jmbsvicetto said, this feature was introduced many months before EAPI=0 will be finally approved :) .
[21:55:08] <dleverton> Not the point
[21:55:59] <dleverton> EAPI 0 isn't absolutely frozen, purely because it's not realistic to expect a 100% perfect spec to be written retroactively, and therefore it's likely that there will be the need for small changes for a long time
[21:56:09] hays__ [n=hays@unaffiliated/hays] has joined #gentoo-portage
[21:56:11] <dleverton> But that doesn't mean it's OK to add big new features like that
[21:56:35] <Arfrever> dleverton: It's a small, old feature :) .
[21:56:56] <dleverton> By that argument, you could say that use deps were introduced before EAPI 0 is finally approved, therefore EAPI 0 should have use deps
[21:57:14] <dleverton> It's big in the sense that code written to the current spec will break badly
[21:57:54] <dleverton> And as for "old", all the documentation until recently said that it was only for use in config files.  Even if that was just an oversight, it's hardly fair to penalise people who wrote code assuming the docs were correct
[21:58:43] <zmedico> all is fair in love and war :)
[21:59:02] dleverton wishes certain people wouldn't keep treating this like a war....
[21:59:35] <dleverton> (Not anyone in this discussion, I don't think)
[22:00:14] <reavertm> dleverton: you certainly have some reusable class in paludis code and it should not be *very* hard to implement it just right away and get over with
[22:00:51] <dleverton> It wouldn't be hard to add it to a new EAPI either, and use a magic infra script to handle it until the main profiles/ can use the new EAPI
[22:00:53] <reavertm> besides I doubt it would be introduced in tree immediately
[22:01:00] <tanderson> I personally like a slow conversion where you put the actual support in PMS for EAPI 4 (or we could even rush it into EAPI 3 as that's a ways off) and then have an infra script
[22:02:24] <dleverton> That sounds like the best idea to me, too
[22:02:41] dacook [n=schism@fw0nk.net] has quit IRC: "leaving"
[22:03:10] <tanderson> dleverton: given that EAPI 3 still isn't coming out for awhile, do you see anything against putting such a thing in EAPI 3 ?
[22:03:18] <tanderson> It's not that much of a change admittedly
[22:03:31] <dleverton> Sounds fine
[22:03:53] <Arfrever> tanderson: ciaranm likes slow conversations only when he likes given idea. ciaranm (after notification probably from dleverton) recently drastically changed definition of nonfatal() in PMS without agreement of developers of other package managers.
[22:03:57] <dleverton> Some people won't be too happy if it's opened up for new features in general, but just this one should be OK
[22:04:31] <dleverton> Arfrever: that was just clarifying the wording, not a "drastic change"
[22:04:40] <tanderson> Arfrever: can I have a link to the pms commit please?
[22:04:48] <dleverton> And you had the chance to disagree on the mailing list
[22:05:02] <Arfrever> dleverton: There was no agreement that it was clarification.
[22:05:25] <Arfrever> dleverton: I wasn't subscribed to that mailing list, when he posted that patch.
[22:05:36] <Arfrever> (I subscribed some time later.)
[22:06:16] <Arfrever> dleverton: Anyway such drastic change should be first discussed on gentoo-dev mailing list, which has more interested subscribers.
[22:06:49] <dleverton> Feel free to bring it up if you think the other behaviour is better
[22:06:55] <dleverton> There are arguments both ways
[22:07:08] <tanderson> Doesn't look like a drastic change to me fwiw
[22:07:28] <tanderson> Noone on the gentoo pms team had a problem with it either
[22:08:10] <Arfrever> It disallows to usefully use nonfatal() with functions from eclasses without modifying these functions.
[22:08:21] <Arfrever> tanderson: ciaranm didn't explain consequences.
[22:08:57] <dleverton> It's debatable whether we want to change the behaviour of existing eclass functions without modifying them
[22:09:23] <reavertm> if that commit changes expected behaviour, then should be reverted
[22:09:30] <dleverton> For example, if a function dies as the non-last statement, nonfatal won't cause it to return an error, it'll just proceed with the rest of the function
[22:10:26] <dleverton> reavertm: depends who's doing the expecting
[22:11:13] <reavertm> indeed
[22:14:27] <reavertm> and that's the problem
[22:15:04] <Arfrever> tanderson: See http://dpaste.com/83744/
[22:15:28] <tanderson> found it already, thanks though
[22:15:44] <Arfrever> ciaranm posted the patch about 15-20 minutes after discussion about nonfatal() began.
[22:15:57] pva [n=pva@gentoo/developer/pva] has quit IRC: Read error: 60 (Operation timed out)
[22:17:55] <Arfrever> Anyway my point is that ciaranm, dleverton etc. are unfair in PMS development.
[22:19:02] <dleverton> You had the chance to object (even if you couldn't reply directly to the original mail, no-one would have objected if you'd started a new thread with an explanation of why)
[22:19:11] <dleverton> Anyway, I'm going to raise the issue on -dev@
[22:19:23] <zmedico> Arfrever: btw, what does the DT stand for in those QA_* variables?
[22:20:05] <zmedico> (and thanks for doing that stuff)
[22:21:30] <Arfrever> AFAIK .dynamic tag (i.e. a tag in .dynamic section)
[22:22:23] <zmedico> ah, ok. thanks
[22:22:38] <Arfrever> dleverton: I was planning to raise this issue on gentoo-dev mailing list, but I was busy with other things :) .
[22:23:10] <dleverton> Arfrever: OK
[22:25:34] <zmedico> Arfrever: comparing the QA_PRESTRIPPED to the QA_SONAME code, do we need to add a sed -e "/^\$/d" to removed empty lines in the QA_SONAME code?
[22:25:38] <Arfrever> dleverton: Do you still plan to raise this issue on gentoo-dev mailing list, or will you give me some time to write an e-mail about it?
[22:26:05] <dleverton> Arfrever: I was just writing up a mail now, I'll let you see it before I send it, in case there's anything you think is horribly wrong
[22:26:43] <Arfrever> dleverton: Behavior desired by you will be probably horribly wrong :) .
[22:27:14] <dleverton> :-P
[22:27:16] <dleverton> We'll see
[22:27:47] <Arfrever> dleverton: Please attach IRC logs.
[22:28:01] <Arfrever> (With mentioned timezone.)
[22:28:12] <dleverton> Arfrever: I intended the mail to be purely about the merits of the different possible behaviours
[22:28:31] <Arfrever> dleverton: My IRC log is in UTC+2.
[22:28:36] <zmedico> Arfrever: nevermind that last question, I see that it doesn't matter
[22:29:22] <zmedico> QA_PRESTRIPPED uses [[ -s $log ]]
[22:29:32] <zmedico> and that's the difference
[22:29:38] Zoolooc [n=fredsiba@p549526A4.dip0.t-ipconnect.de] has joined #gentoo-portage
[22:33:32] <Arfrever> zmedico: I think that sed -e "/^\$/d" should be added to QA_{SONAME,DT_NEEDED} to avoid potential empty lines between files in eqawarn message.
[22:33:48] <zmedico> oh, good idea
[22:40:12] <dleverton> Arfrever, anyone else who cares: http://dpaste.com/83757/
[22:40:43] rafael_martins [n=rafael@unaffiliated/rafaelmartins/x-162351] has joined #gentoo-portage
[22:42:15] <Arfrever> dleverton: 'die --force' is a good idea.
[22:42:40] <dleverton> Yeah, that's a possibility, I'll add that too
[22:43:51] <reavertm> I don't see any use case for nonfatal
[22:44:47] <reavertm> if someone wants to "nonfatal <sth>" then probably <sth> should not die itself (and if it does, then it should be fixed)
[22:44:56] <dleverton> reavertm: I think the main thing is just to die with a more informative message than the default, but there are other possibilities
[22:45:41] kallamej [n=kallamej@gentoo/developer/kallamej] has joined #gentoo-portage
[22:45:44] <dleverton> Arfrever: http://dpaste.com/83762/
[22:45:47] <Arfrever> dleverton: The only problem which would happen if eclasses aren't modified to support die() from older EAPIs is that die message would include "--force" prepended. New versions of package managers can silently ignore --force in older EAPIs.
[22:46:44] reavertm just waiting to options like --force, --really-force, --no,seriously-really-force-this-time,seriously..
[22:47:01] <Arfrever> dleverton: "--force building failed" isn't too ugly :) .
[22:47:34] <dleverton> It's not terribly, but it would be a bit messy to see it frequently
[22:47:38] <dleverton> *terrible
[22:48:08] <Arfrever> New versions of package managers wouldn't print --force even in older EAPIs.
[22:48:21] <dleverton> Possibly
[22:48:54] <Arfrever> dleverton: DIE_FORCE=1 die "building failed" would avoid this problem :) .
[22:49:07] <dleverton> That could work
[22:50:17] <reavertm> nonfatal shoo || DIE_FORCE=1 die "building failed"
[22:50:31] <reavertm> seriously you want to allow that?
[22:51:01] <Arfrever> dleverton: Please consider changing that example to: cd foo || DIE_FORCE=1 die "cd failed"
[22:52:52] <dleverton> Arfrever: http://dpaste.com/83767/
[22:53:53] rafaelmartins [n=rafael@unaffiliated/rafaelmartins/x-162351] has quit IRC: Read error: 110 (Connection timed out)
[22:53:59] mpagano [n=mpagano@gentoo/developer/mpagano] has joined #gentoo-portage
[22:54:08] <Arfrever> dleverton: OK. Please send it.
[22:55:23] rafael_martins [n=rafael@unaffiliated/rafaelmartins/x-162351] has quit IRC: "http://gentoo-br.net"
[22:56:36] rafaelmartins [n=rafael@unaffiliated/rafaelmartins/x-162351] has joined #gentoo-portage
[22:59:13] <dleverton> Arfrever: sent, thanks for the feedback
[22:59:31] slonopotamus [n=slonopot@80.90.124.131] has quit IRC: Read error: 104 (Connection reset by peer)
[23:05:12] slonopotamus [n=slonopot@80.90.124.131] has joined #gentoo-portage
[23:42:15] zmedico [n=zmedico@gentoo/developer/zmedico] has quit IRC: Remote closed the connection
[23:46:59] zmedico [n=zmedico@gentoo/developer/zmedico] has joined #gentoo-portage
[23:58:15] dma` [n=dma@cpe-069-132-191-004.carolina.res.rr.com] has joined #gentoo-portage
### Log session terminated at 2009-08-22T00:00:00 ###

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Sat, 22 Aug 2009 00:40:04 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> I would like to also notice that (not yet approved by Council)
> definition of nonfatal() in PMS was recently drastically changed
> without proper discussion with developers of other package managers.
> [1] was sent about 20 minutes after discussion about nonfatal()
> started in #gentoo-portage in about 2009-08-06 19:45 UTC. (I'm
> attaching IRC log from #gentoo-portage (in UTC+02 timezone).) I think
> that such drastic changes should be first discussed on gentoo-dev
> mailing list.

There was no change to the definition of nonfatal. There was a
clarification of the wording after it became clear that there was room
to misinterpret the intent of the original wording, and it went through
the usual Council-mandated process for such a change.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1275 bytes --]

2009-08-22 00:51:14 Ciaran McCreesh napisał(a):
> On Sat, 22 Aug 2009 00:40:04 +0200
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > I would like to also notice that (not yet approved by Council)
> > definition of nonfatal() in PMS was recently drastically changed
> > without proper discussion with developers of other package managers.
> > [1] was sent about 20 minutes after discussion about nonfatal()
> > started in #gentoo-portage in about 2009-08-06 19:45 UTC. (I'm
> > attaching IRC log from #gentoo-portage (in UTC+02 timezone).) I think
> > that such drastic changes should be first discussed on gentoo-dev
> > mailing list.
> 
> There was no change to the definition of nonfatal.
 
There was a change regardless of what you think.

> There was a clarification of the wording after it became clear that there
> was room to misinterpret the intent of the original wording, and it went
> through the usual Council-mandated process for such a change.

This sentence contradicts your first sentence. Additionally you had deceived
Christian Faulhammer by not presenting negative consequences of your patch and
your interpretation of original wording of definition of nonfatal().

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

On Sat, 22 Aug 2009 01:15:18 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > There was no change to the definition of nonfatal.
>  
> There was a change regardless of what you think.

No, you were misreading the original wording (which I quite happy
admit was wide open for misreading), hence the need for the
clarification.

> > There was a clarification of the wording after it became clear that
> > there was room to misinterpret the intent of the original wording,
> > and it went through the usual Council-mandated process for such a
> > change.
> 
> This sentence contradicts your first sentence.

No, it doesn't.

The original wording used the phrase "abort the build process due to a
failure". The intent was that this would cover commands that had
language like "Failure behaviour is EAPI dependent as per
section~\ref{sec:failure-behaviour}.".

The language for 'die' does not say "due to a failure", and so was not
supposed to be affected by 'nonfatal'.

However, that wasn't explicit, so your misreading of the intent of the
document is entirely understandable. That is why we fixed it.

> Additionally you had deceived Christian Faulhammer by not presenting
> negative consequences of your patch and your interpretation of
> original wording of definition of nonfatal().

The only consequence of the patch was to clarify what was already
stated.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1791 bytes --]

2009-08-22 01:28:17 Ciaran McCreesh napisał(a):
> On Sat, 22 Aug 2009 01:15:18 +0200
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > > There was no change to the definition of nonfatal.
> >  
> > There was a change regardless of what you think.
> 
> No, you were misreading the original wording

The original wording didn't disallow affecting die(). Not disallowed things
are always allowed.

> > > There was a clarification of the wording after it became clear that
> > > there was room to misinterpret the intent of the original wording,
> > > and it went through the usual Council-mandated process for such a
> > > change.
> > 
> > This sentence contradicts your first sentence.
> 
> No, it doesn't.

"it went through the usual Council-mandated process for such a change" clearly
contradicts "There was no change".

> The original wording used the phrase "abort the build process due to a
> failure". The intent was that this would cover commands that had
> language like "Failure behaviour is EAPI dependent as per
> section~\ref{sec:failure-behaviour}.".
> 
> The language for 'die' does not say "due to a failure", and so was not
> supposed to be affected by 'nonfatal'.
> 
> However, that wasn't explicit, so your misreading of the intent of the
> document is entirely understandable. That is why we fixed it.

You broke it.

> > Additionally you had deceived Christian Faulhammer by not presenting
> > negative consequences of your patch and your interpretation of
> > original wording of definition of nonfatal().
> 
> The only consequence of the patch was to clarify what was already
> stated.

It wasn't stated as I said above in my 2 first sentences in this e-mail.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]

On Sat, 22 Aug 2009 01:39:41 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > > There was a change regardless of what you think.
> > 
> > No, you were misreading the original wording
> 
> The original wording didn't disallow affecting die(). Not disallowed
> things are always allowed.

Er, no. The wording describes the extent of what die and nonfatal do.
There's nothing in the die description about it being affected by
nonfatal, and nothing in the nonfatal description about affecting die,
so neither affect each other.

PMS doesn't say "nonfatal must not chmod +s ${D}/bin/sh", so do you
believe that nonfatal would be allowed to do that too?

> > > > There was a clarification of the wording after it became clear
> > > > that there was room to misinterpret the intent of the original
> > > > wording, and it went through the usual Council-mandated process
> > > > for such a change.
> > > 
> > > This sentence contradicts your first sentence.
> > 
> > No, it doesn't.
> 
> "it went through the usual Council-mandated process for such a
> change" clearly contradicts "There was no change".

There was a change in wording to better convey the original intent.
There was no change in behaviour.

> > The original wording used the phrase "abort the build process due
> > to a failure". The intent was that this would cover commands that
> > had language like "Failure behaviour is EAPI dependent as per
> > section~\ref{sec:failure-behaviour}.".
> > 
> > The language for 'die' does not say "due to a failure", and so was
> > not supposed to be affected by 'nonfatal'.
> > 
> > However, that wasn't explicit, so your misreading of the intent of
> > the document is entirely understandable. That is why we fixed it.
> 
> You broke it.

I made the wording more clearly present the original intent. That is
all. 

> > > Additionally you had deceived Christian Faulhammer by not
> > > presenting negative consequences of your patch and your
> > > interpretation of original wording of definition of nonfatal().
> > 
> > The only consequence of the patch was to clarify what was already
> > stated.
> 
> It wasn't stated as I said above in my 2 first sentences in this
> e-mail.

It was. The extent of the behaviour of nonfatal is described in PMS.
You can't go around inventing magic new behaviour for it that isn't
specified.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 883 bytes --]

2009-08-22 01:43:54 Ciaran McCreesh napisał(a):
> On Sat, 22 Aug 2009 01:39:41 +0200
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > > > > There was a clarification of the wording after it became clear
> > > > > that there was room to misinterpret the intent of the original
> > > > > wording, and it went through the usual Council-mandated process
> > > > > for such a change.
> > > > 
> > > > This sentence contradicts your first sentence.
> > > 
> > > No, it doesn't.
> > 
> > "it went through the usual Council-mandated process for such a
> > change" clearly contradicts "There was no change".
> 
> There was a change in wording to better convey the original intent.
> There was no change in behaviour.

There was a change in behavior of 'nonfatal eclass_function_which_sometimes_calls_die'.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Sun, 23 Aug 2009 04:48:56 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > There was a change in wording to better convey the original intent.
> > There was no change in behaviour.
> 
> There was a change in behavior of 'nonfatal
> eclass_function_which_sometimes_calls_die'.

No there wasn't. The behaviour specified by PMS both before and after
the patch remains exactly the same. The only thing the patch did was
make the wording much clearer, so people can no longer make the
(perfectly understandble) misinterpretation of the intent that you have
made.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Fri, 21 Aug 2009 21:56:41 +0100
David Leverton <levertond@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?


-- 
fonts,                             Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

Hi,

Ryan Hill <dirtyepic@gentoo.org>:

> On Fri, 21 Aug 2009 21:56:41 +0100
> David Leverton <levertond@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).

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

On Mon, Aug 24, 2009 at 08:20:44PM +0200, Christian Faulhammer wrote:
> Hi,
> 
> Ryan Hill <dirtyepic@gentoo.org>:
> 
> > On Fri, 21 Aug 2009 21:56:41 +0100
> > David Leverton <levertond@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 must agree here too as a PMS team member. so 'me too' :P

-- 
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Marijn Schouten (hkBst)]

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

Christian Faulhammer wrote:
> Hi,
> 
> Ryan Hill <dirtyepic@gentoo.org>:
> 
>> On Fri, 21 Aug 2009 21:56:41 +0100
>> David Leverton <levertond@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-----

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Tue, 25 Aug 2009 12:21:46 +0200
"Marijn Schouten (hkBst)" <hkBst@gentoo.org> wrote:
> 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?

We aren't. nonfatal is done as a prefix rather than a --switch for the
same reason that 'nice' is.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Zac Medico]

Ryan Hill wrote:
> On Fri, 21 Aug 2009 21:56:41 +0100
> David Leverton <levertond@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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Mon, 24 Aug 2009 15:09:52 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> > 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.

Probably not the best choice of name... 'assert' is already in use for
checking PIPESTATUS.

The other problem with doing things that way is that people have to
start writing code that does an EAPI check just to be able to force a
die. An IGNORE_NONFATAL environment variable, whilst slightly ickier,
avoids that issue if we do change the definitions of die and nonfatal.

*shrug* I still think the way it was originally worded is the best
option. Otherwise we'll just replace the "some helpers die, some don't,
and no-one knows which" situation with "some eclass functions are
nonfatal aware, some aren't, and no-one knows which", with an added
side helping of "people need to find out whether any of the callers in
any overlay anywhere expect this function to work with nonfatal before
changing it".

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]