Re: [gentoo-dev] Calling die in a subshell
On 06/15/13 19:02, Mike Gilbert wrote: On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 15 Jun 2013 12:56:00 -0400 Mike Gilbert flop...@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
On 6/17/2013 4:10 PM, viv...@gmail.com wrote: On 06/15/13 19:02, Mike Gilbert wrote: On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 15 Jun 2013 12:56:00 -0400 Mike Gilbert flop...@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.
Re: [gentoo-dev] Calling die in a subshell
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
[gentoo-dev] Calling die in a subshell
-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
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Calling die in a subshell
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
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
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Calling die in a subshell
On Sat, Jun 15, 2013 at 12:16 PM, Ulrich Mueller u...@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
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
On Sat, 15 Jun 2013 18:16:32 +0200 Ulrich Mueller u...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Calling die in a subshell
-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
On Sat, 15 Jun 2013 18:24:13 +0200 Tom Wijsman tom...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Calling die in a subshell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Jun 2013 18:41:18 +0200 hasufell hasuf...@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
-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 hasuf...@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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Jun 2013 18:45:05 +0200 hasufell hasuf...@gentoo.org wrote: On 06/15/2013 06:43 PM, Ciaran McCreesh wrote: On Sat, 15 Jun 2013 18:41:18 +0200 hasufell hasuf...@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
On Sat, Jun 15, 2013 at 12:42 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 15 Jun 2013 18:24:13 +0200 Tom Wijsman tom...@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
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
On Sat, 15 Jun 2013 12:56:00 -0400 Mike Gilbert flop...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Calling die in a subshell
On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 15 Jun 2013 12:56:00 -0400 Mike Gilbert flop...@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
Dnia 2013-06-15, o godz. 18:25:15 Ulrich Mueller u...@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 signature.asc Description: PGP signature
