[gentoo-dev] Calling die in a subshell

[gentoo-dev] Calling die in a subshell

[Mike Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The devmanual warns that calling die in a subshell does not work.

http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html

This warning has been obsolete for some time; modern versions of
Portage handle die in a subshell just fine.

In fact, at least a couple of eclasses rely on this behavior. For
example, python-r1 uses subshells created by multiprocessing.eclass to
implement parallel "sub-phase" functions, any of which may call die on
failure.

Are there any objections to removing this warning from the devmanual?

Also, I believe there may be a question or two on the recruiting
quizzes that would need to be updated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlG8kQUACgkQC77qH+pIQ6RMcAD/Ub0qkpXi/6tjNC/vHTXr2lLu
iprwtszsDnZGLOkmVKcA/R85pTIBT3Udo0Gc2/g2TJo6uzG8ppDbMc9bSHMgQtFf
=1qx7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Calling die in a subshell

[Diego Elio Pettenò]

On 15/06/2013 17:06, Mike Gilbert wrote:
> Are there any objections to removing this warning from the devmanual?

Please, go for it.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Calling die in a subshell

[Ulrich Mueller]

>>>>> On Sat, 15 Jun 2013, Mike Gilbert wrote:

> The devmanual warns that calling die in a subshell does not work.

> http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html

> This warning has been obsolete for some time; modern versions of
> Portage handle die in a subshell just fine.

> In fact, at least a couple of eclasses rely on this behavior. For
> example, python-r1 uses subshells created by multiprocessing.eclass
> to implement parallel "sub-phase" functions, any of which may call
> die on failure.

> Are there any objections to removing this warning from the
> devmanual?

PMS doesn't guarantee that die works correctly in a subshell:
http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3

So the devmanual agrees with the spec, and the eclasses need to be
fixed.

Ulrich

Re: [gentoo-dev] Calling die in a subshell

[hasufell]

On 06/15/2013 06:16 PM, Ulrich Mueller wrote:
> 
> PMS doesn't guarantee that die works correctly in a subshell:
> http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3
> 
> So the devmanual agrees with the spec, and the eclasses need to be
> fixed.
> 

How does that make any sense?

Re: [gentoo-dev] Calling die in a subshell

[Diego Elio Pettenò]

On 15/06/2013 17:19, hasufell wrote:
> How does that make any sense?
> 

It does not, but I don't remember anybody trying to assert that PMS
makes sense in quite a long time.

(Yes I still think that the PMS is 90% a waste of time)

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Calling die in a subshell

[Mike Gilbert]

On Sat, Jun 15, 2013 at 12:16 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>> Are there any objections to removing this warning from the
>> devmanual?
>
> PMS doesn't guarantee that die works correctly in a subshell:
> http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3
>
> So the devmanual agrees with the spec, and the eclasses need to be
> fixed.
>
> Ulrich
>

I see mgorny has already filed a bug.

https://bugs.gentoo.org/show_bug.cgi?id=465008

So, I guess I will just patiently wait for EAPI 6.

Re: [gentoo-dev] Calling die in a subshell

[Tom Wijsman]

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

On Sat, 15 Jun 2013 18:16:32 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sat, 15 Jun 2013, Mike Gilbert wrote:
> 
> > The devmanual warns that calling die in a subshell does not work.
> 
> > http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html
> 
> > This warning has been obsolete for some time; modern versions of
> > Portage handle die in a subshell just fine.
> 
> > In fact, at least a couple of eclasses rely on this behavior. For
> > example, python-r1 uses subshells created by multiprocessing.eclass
> > to implement parallel "sub-phase" functions, any of which may call
> > die on failure.
> 
> > Are there any objections to removing this warning from the
> > devmanual?
> 
> PMS doesn't guarantee that die works correctly in a subshell:
> http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3
> 
> So the devmanual agrees with the spec, and the eclasses need to be
> fixed.

What does it take to change future specifications to guarantee this?
What's holding this from becoming guaranteed? Why not fix the specs?

When we're considering changing this, just a reference isn't enough;
please state why it is "_not_ guaranteed". What is the reasoning?

Thank you in advance.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Calling die in a subshell

[Ulrich Mueller]

>>>>> On Sat, 15 Jun 2013, hasufell  wrote:

>> PMS doesn't guarantee that die works correctly in a subshell:
>> http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3
>> 
>> So the devmanual agrees with the spec, and the eclasses need to be
>> fixed.

> How does that make any sense?

It makes perfect sense. The specification doesn't require that the
package manager's die function works in a subshell, so ebuilds and
eclasses cannot rely on such behaviour.

If you want a different behaviour for future EAPIs, then PMS needs to
be changed.

Ulrich

Re: [gentoo-dev] Calling die in a subshell

[hasufell]

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

On 06/15/2013 06:24 PM, Tom Wijsman wrote:
> 
> Why not fix the specs?
> 


from council log
http://www.gentoo.org/proj/en/council/meeting-logs/20120911.txt

<Chainsaw> Okay for EAPI 5. *Nothing* gets applied retroactively. *EVER*


So that means some people think it doesn't even matter what the issue
is. We never fix the spec, we just enhance it.

Oh, you asked for reasoning...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRvJkuAAoJEFpvPKfnPDWz3tQH/2obXhpX8yDpmJJdzu5xdEOK
I5K+RM8FJoqdNwTe/V1DPvr/aNfr8dUBCisge6mjJ999pb1jVG3FhTNIwFBOI2UE
HZeMdnUtvSv3ind6FyL4bpRYGLbk9iTHEvOrZd0P92cEhtawyLwjDx4r2Ux+0ucM
y5UaLXQlFw9tu8bW/eyouY7an0hg6CzMbGzImjAWGgb6O/PtTzcm0UWPZrNiQWZ7
jORvS1m/MHrJLM3EGabUsgp+ak6QOEeVKILC2YNe3XjWWhMlLNKt14BWLiWngkog
LUnVDJ7eDyJjbMAcAqAW48rHE0dxUVgexQC7bMd5pLSRTuucOQGQmf9mrFoiVeo=
=gerD
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Calling die in a subshell

[Ciaran McCreesh]

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

On Sat, 15 Jun 2013 18:24:13 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:
> What does it take to change future specifications to guarantee this?

You can have it from EAPI 6 onwards.

> What's holding this from becoming guaranteed? Why not fix the specs?

The specs accurately reflect Portage behaviour at the time the specs
were approved. The point of a stable EAPI is that once approved it
doesn't change.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Calling die in a subshell

[Ciaran McCreesh]

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

On Sat, 15 Jun 2013 18:41:18 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 06/15/2013 06:24 PM, Tom Wijsman wrote:
> > Why not fix the specs?
> 
> from council log
> http://www.gentoo.org/proj/en/council/meeting-logs/20120911.txt
> 
> <Chainsaw> Okay for EAPI 5. *Nothing* gets applied retroactively.
> *EVER*
> 
> So that means some people think it doesn't even matter what the issue
> is. We never fix the spec, we just enhance it.
> 
> Oh, you asked for reasoning...

If you want the reasoning for that decision, you should look at the
entire log, and not just one line of it.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlG8mb0ACgkQ96zL6DUtXhFoiQCaA5Y+T4UY2lvzGFg8VZXcl4df
0VMAoJf2dqE3T6ztIKCaMc/jXzTUxJOw
=bD6A
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Calling die in a subshell

[hasufell]

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

On 06/15/2013 06:43 PM, Ciaran McCreesh wrote:
> On Sat, 15 Jun 2013 18:41:18 +0200 hasufell <hasufell@gentoo.org>
> wrote:
>> On 06/15/2013 06:24 PM, Tom Wijsman wrote:
>>> Why not fix the specs?
> 
>> from council log 
>> http://www.gentoo.org/proj/en/council/meeting-logs/20120911.txt
> 
>> <Chainsaw> Okay for EAPI 5. *Nothing* gets applied
>> retroactively. *EVER*
> 
>> So that means some people think it doesn't even matter what the
>> issue is. We never fix the spec, we just enhance it.
> 
>> Oh, you asked for reasoning...
> 
> If you want the reasoning for that decision, you should look at
> the entire log, and not just one line of it.
> 
> 

I was not talking about that decision. Stop derailing threads on -dev.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRvJoRAAoJEFpvPKfnPDWzSE4H/iFVg/nfbMczic8xj7h/46A5
noMJ29KdJYaT9CKan9gD3vEpH8GuPwaZYSXIrfagPI3FV7ovJS6+hluGuTuzoaiQ
FL9Zh3aam4mO6P5ds7yKz53Her5uM6N/wf58/81EFy4bVtNebWDbYmD8xvC/oe7i
U6k4gH/PWxSd8HJCngA5lRk4/xLPeR5YKfWsvOOiQEJ+908s8Vw7nEtGIvlXKRjN
+ujTlxW182jauWlV0S92KgNdsMqWk8OctJnWT2G02PqqQ6DzXkxUeKbakN9STbVM
SVVbWJLTTKvQ+lfYGcIJroaA7RhR0GQqQ6HvebfIrgQiTY6kfzHpQqElA9iH6qs=
=2cmH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Calling die in a subshell

[Ciaran McCreesh]

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

On Sat, 15 Jun 2013 18:45:05 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 06/15/2013 06:43 PM, Ciaran McCreesh wrote:
> > On Sat, 15 Jun 2013 18:41:18 +0200 hasufell <hasufell@gentoo.org>
> > wrote:
> >> On 06/15/2013 06:24 PM, Tom Wijsman wrote:
> >>> Why not fix the specs?
> > 
> >> from council log 
> >> http://www.gentoo.org/proj/en/council/meeting-logs/20120911.txt
> > 
> >> <Chainsaw> Okay for EAPI 5. *Nothing* gets applied
> >> retroactively. *EVER*
> > 
> >> So that means some people think it doesn't even matter what the
> >> issue is. We never fix the spec, we just enhance it.
> > 
> >> Oh, you asked for reasoning...
> > 
> > If you want the reasoning for that decision, you should look at
> > the entire log, and not just one line of it.
> > 
> > 
> 
> I was not talking about that decision. Stop derailing threads on -dev.

Then I appear to have misunderstood what you wanted reasoning for.
Please explain further. Chances are I can give you an answer, since
I've been involved in most of the policy-related discussions for EAPIs
and PMS.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlG8m0IACgkQ96zL6DUtXhETyACg0WVMQ4QslQezKtzOCpo+gGys
tNsAoLq4a15J0hhNG657HvLckBXw++f3
=+LFr
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Calling die in a subshell

[Mike Gilbert]

On Sat, Jun 15, 2013 at 12:42 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 15 Jun 2013 18:24:13 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
>> What does it take to change future specifications to guarantee this?
>
> You can have it from EAPI 6 onwards.
>
>> What's holding this from becoming guaranteed? Why not fix the specs?
>
> The specs accurately reflect Portage behaviour at the time the specs
> were approved. The point of a stable EAPI is that once approved it
> doesn't change.
>

From the council log, the main objection I saw was that we didn't want
to change the behavior of existing ebuilds.

In this particular case, we know that Portage has been properly
handling die in a subshell since at least EAPI 4 was approved.

I don't use Paludis, but we may have a similar situation there.

If we find that all known implementations of PMS/EAPI 4 have
implemented a certain behavior, making a change to that version of PMS
to properly document the behavior seems reasonable.

Re: [gentoo-dev] Calling die in a subshell

[hasufell]

On 06/15/2013 06:56 PM, Mike Gilbert wrote:
> 
> If we find that all known implementations of PMS/EAPI 4 have
> implemented a certain behavior, making a change to that version of PMS
> to properly document the behavior seems reasonable.
> 

Right, that's why my quote from the council log does not make sense.

Re: [gentoo-dev] Calling die in a subshell

[Ciaran McCreesh]

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

On Sat, 15 Jun 2013 12:56:00 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> If we find that all known implementations of PMS/EAPI 4 have
> implemented a certain behavior, making a change to that version of PMS
> to properly document the behavior seems reasonable.

Part of the point of EAPI stability is that it doesn't just apply to
current versions of package manglers.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Calling die in a subshell

[Mike Gilbert]

On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 15 Jun 2013 12:56:00 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> If we find that all known implementations of PMS/EAPI 4 have
>> implemented a certain behavior, making a change to that version of PMS
>> to properly document the behavior seems reasonable.
>
> Part of the point of EAPI stability is that it doesn't just apply to
> current versions of package manglers.
>

So look back at the first versions which implemented EAPI 4 support,
and see what the behavior was implemented at the point in time.

Re: [gentoo-dev] Calling die in a subshell

[Michał Górny]

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

Dnia 2013-06-15, o godz. 18:25:15
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Sat, 15 Jun 2013, hasufell  wrote:
> 
> >> PMS doesn't guarantee that die works correctly in a subshell:
> >> http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3
> >> 
> >> So the devmanual agrees with the spec, and the eclasses need to be
> >> fixed.
> 
> > How does that make any sense?
> 
> It makes perfect sense. The specification doesn't require that the
> package manager's die function works in a subshell, so ebuilds and
> eclasses cannot rely on such behaviour.
> 
> If you want a different behaviour for future EAPIs, then PMS needs to
> be changed.

And there's a bug open for it already:

https://bugs.gentoo.org/show_bug.cgi?id=465008

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Calling die in a subshell

[Ulrich Mueller]

>>>>> On Sat, 15 Jun 2013, Ulrich Mueller wrote:

>>> PMS doesn't guarantee that die works correctly in a subshell:
>>> http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3
>>> 
>>> So the devmanual agrees with the spec, and the eclasses need to be
>>> fixed.

>> How does that make any sense?

> It makes perfect sense. The specification doesn't require that the
> package manager's die function works in a subshell, so ebuilds and
> eclasses cannot rely on such behaviour.

It turns out that killing the main process (as both Portage and
Paludis do) isn't sufficient in all cases, thanks to Ciaran for
pointing this out. It will already fail for something simple like:

    foo | ( bar || die )

See bug 465008 comment #2 and following.

> If you want a different behaviour for future EAPIs, then PMS
> needs to be changed.

Ulrich

Re: [gentoo-dev] Calling die in a subshell

[vivo75]

On 06/15/13 19:02, Mike Gilbert wrote:
> On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Sat, 15 Jun 2013 12:56:00 -0400
>> Mike Gilbert <floppym@gentoo.org> wrote:
>>> If we find that all known implementations of PMS/EAPI 4 have
>>> implemented a certain behavior, making a change to that version of PMS
>>> to properly document the behavior seems reasonable.
>> Part of the point of EAPI stability is that it doesn't just apply to
>> current versions of package manglers.
>>
> So look back at the first versions which implemented EAPI 4 support,
> and see what the behavior was implemented at the point in time.
>
it make sense but it stretch things a lot.

Is it possible to:
- keep an open bug (tracker) on named eclasses/ebuilds, so we (users and
devs) know that there is a (teoric) fallacy
- approve it for EAPI 6
- move all the eapi/ebuilds to EAPI 6
- close the bugs as WONT-FIX

In any case it should be easy to port an ebuild from EAPI4 to 6, if
gentoers want to keep things simple it could be more a version 5a than 6

regards

Re: [gentoo-dev] Calling die in a subshell

[Mike Gilbert]

On 6/17/2013 4:10 PM, vivo75@gmail.com wrote:
> On 06/15/13 19:02, Mike Gilbert wrote:
>> On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>>> On Sat, 15 Jun 2013 12:56:00 -0400
>>> Mike Gilbert <floppym@gentoo.org> wrote:
>>>> If we find that all known implementations of PMS/EAPI 4 have
>>>> implemented a certain behavior, making a change to that version of PMS
>>>> to properly document the behavior seems reasonable.
>>> Part of the point of EAPI stability is that it doesn't just apply to
>>> current versions of package manglers.
>>>
>> So look back at the first versions which implemented EAPI 4 support,
>> and see what the behavior was implemented at the point in time.
>>
> it make sense but it stretch things a lot.
> 
> Is it possible to:
> - keep an open bug (tracker) on named eclasses/ebuilds, so we (users and
> devs) know that there is a (teoric) fallacy
> - approve it for EAPI 6
> - move all the eapi/ebuilds to EAPI 6
> - close the bugs as WONT-FIX
> 
> In any case it should be easy to port an ebuild from EAPI4 to 6, if
> gentoers want to keep things simple it could be more a version 5a than 6
> 
> regards

What on earth is a "teoric fallacy"?

I'm fine with waiting for EAPI 6 if necessary.

I would not find a tracker bug very useful, and have no intention of
starting one.

[gentoo-dev] Re: Calling die in a subshell

[Duncan]

Mike Gilbert posted on Mon, 17 Jun 2013 16:49:00 -0400 as excerpted:

> On 6/17/2013 4:10 PM, vivo75@gmail.com wrote:

>> Is it possible to:

>> - keep an open bug (tracker) on named eclasses/ebuilds, so we (users
>> and devs) know that there is a (teoric) fallacy

> What on earth is a "teoric fallacy"?

My question too.  Wictionary and google both appear to agree, however, 
that while "teoric" isn't English, it's Catalan (or Aranese/Occitan, the 
area is NE Spain into south France) for "theoretical", which it /is/ 
close enough sounding/spelling to, to make sense as having the same 
original root (which wikipedia traces to late Latin from ancient Greek).

http://en.wiktionary.org/wiki/te%C3%B2ric

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Calling die in a subshell

[vivo75]

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

On 06/18/13 09:06, Duncan wrote:
>> > What on earth is a "teoric fallacy"?
> My question too.  Wictionary and google both appear to agree, however, 
> that while "teoric" isn't English, it's Catalan (or Aranese/Occitan, the 
> area is NE Spain into south France) for "theoretical", which it /is/ 
> close enough sounding/spelling to, to make sense as having the same 
> original root (which wikipedia traces to late Latin from ancient Greek).
>
> http://en.wiktionary.org/wiki/te%C3%B2ric
near enough, it was an (unwanted) chimera between Italian and English

[-- Attachment #2: Type: text/html, Size: 1243 bytes --]