Skip Menu |
Report information
Id: 2754
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: tchrist [at] chthon.perl.com
Cc:
AdminCc:

Operating System: All
PatchStatus: (no value)
Severity: low
Type:
Perl Version:
  • 5.11.0
  • 5.25.3
Fixed In: (no value)



To: Gurusamy Sarathy <gsar [...] ActiveState.com>, perl5-porters [...] perl.org
Subject: [BUG] can't exit 0 from CHECK{}
Date: Tue, 28 Mar 2000 08:02:07 -0700
From: Tom Christiansen <tchrist [...] chthon.perl.com>
Download (untitled) / with headers
text/plain 942b
From a CHECK{}, you cannot exit(0). You may exit !0, but not 0. If you put this in /tmp/a and run it: #BEGIN { warn "testing exit from BEGIN"; exit } #BEGIN { warn "testing exit N from BEGIN"; exit 1 } #INIT { warn "testing exit from INIT"; exit } #INIT { warn "testing exit N from INIT"; exit 2 } CHECK { warn "testing exit from CHECK"; exit } #CHECK { warn "testing exit N from CHECK"; exit 3 } #END { warn "testing exit from END"; exit } #END { warn "testing exit N from END"; exit 4 } print "i am now the main program\n"; warn "testing exit 5 from main"; exit 5; die "XXX"; You will get: % perl /tmp/a testing exit from CHECK at /tmp/a line 7. i am now the main program testing exit 5 from main at /tmp/a line 14. Exit 5 If you switch the comment on the two CHECKs, you get % perl /tmp/a testing exit N from CHECK at /tmp/a line 8. Exit 3 --tom
[tchrist@chthon.perl.com - Tue Mar 28 03:39:19 2000]: Show quoted text
> From a CHECK{}, you cannot exit(0). You may exit !0, but not 0. > If you put this in /tmp/a and run it: > > #BEGIN { warn "testing exit from BEGIN"; exit } > #BEGIN { warn "testing exit N from BEGIN"; exit 1 } > > #INIT { warn "testing exit from INIT"; exit } > #INIT { warn "testing exit N from INIT"; exit 2 } > > CHECK { warn "testing exit from CHECK"; exit } > #CHECK { warn "testing exit N from CHECK"; exit 3 } > > #END { warn "testing exit from END"; exit } > #END { warn "testing exit N from END"; exit 4 } > > print "i am now the main program\n"; > warn "testing exit 5 from main"; > exit 5; > > die "XXX"; > > You will get: > > % perl /tmp/a > testing exit from CHECK at /tmp/a line 7. > i am now the main program > testing exit 5 from main at /tmp/a line 14. > Exit 5 > > If you switch the comment on the two CHECKs, you get > > % perl /tmp/a > testing exit N from CHECK at /tmp/a line 8. > Exit 3
Confirmed this bug is present as of @17821.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
Still present in 5.12.0 RC0. On Tue Mar 28 03:39:19 2000, tchrist@chthon.perl.com wrote: Show quoted text
> From a CHECK{}, you cannot exit(0). You may exit !0, but not 0. > If you put this in /tmp/a and run it: > > #BEGIN { warn "testing exit from BEGIN"; exit } > #BEGIN { warn "testing exit N from BEGIN"; exit 1 } > > #INIT { warn "testing exit from INIT"; exit } > #INIT { warn "testing exit N from INIT"; exit 2 } > > CHECK { warn "testing exit from CHECK"; exit } > #CHECK { warn "testing exit N from CHECK"; exit 3 } > > #END { warn "testing exit from END"; exit } > #END { warn "testing exit N from END"; exit 4 } > > print "i am now the main program\n"; > warn "testing exit 5 from main"; > exit 5; > > die "XXX"; > > You will get: > > % perl /tmp/a > testing exit from CHECK at /tmp/a line 7. > i am now the main program > testing exit 5 from main at /tmp/a line 14. > Exit 5 > > If you switch the comment on the two CHECKs, you get > > % perl /tmp/a > testing exit N from CHECK at /tmp/a line 8. > Exit 3
-- Alexandr Ciornii, http://chorny.net
CC: "OtherRecipients of perl Ticket #2754": ;, perl5-porters [...] perl.org
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
Date: Mon, 12 Apr 2010 13:12:31 +0200
To: Alexandr Ciornii via RT <perlbug-followup [...] perl.org>
From: Abigail <abigail [...] abigail.be>
Download (untitled) / with headers
text/plain 1.4k
On Mon, Apr 12, 2010 at 03:50:52AM -0700, Alexandr Ciornii via RT wrote: Show quoted text
> > On Tue Mar 28 03:39:19 2000, tchrist@chthon.perl.com wrote:
> > From a CHECK{}, you cannot exit(0). You may exit !0, but not 0. > > If you put this in /tmp/a and run it: > > > > #BEGIN { warn "testing exit from BEGIN"; exit } > > #BEGIN { warn "testing exit N from BEGIN"; exit 1 } > > > > #INIT { warn "testing exit from INIT"; exit } > > #INIT { warn "testing exit N from INIT"; exit 2 } > > > > CHECK { warn "testing exit from CHECK"; exit } > > #CHECK { warn "testing exit N from CHECK"; exit 3 } > > > > #END { warn "testing exit from END"; exit } > > #END { warn "testing exit N from END"; exit 4 } > > > > print "i am now the main program\n"; > > warn "testing exit 5 from main"; > > exit 5; > > > > die "XXX"; > > > > You will get: > > > > % perl /tmp/a > > testing exit from CHECK at /tmp/a line 7. > > i am now the main program > > testing exit 5 from main at /tmp/a line 14. > > Exit 5 > > > > If you switch the comment on the two CHECKs, you get > > > > % perl /tmp/a > > testing exit N from CHECK at /tmp/a line 8. > > Exit 3
> > > Still present in 5.12.0 RC0.
And in 5.12.0-RC5 as well. However, it's not a regression for a recent Perl. It behaves the same in 5.10.1, 5.8.[89] and 5.6.2. It is a regression from 5.005_04 though, which will print the expected: testing exit from CHECK at bb line 14. Abigail
Subject: [PSEUDO-PATCH][BUG] can't exit 0 from CHECK{}
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Tue Mar 28 03:39:19 2000, tchrist@chthon.perl.com wrote: Show quoted text
> From a CHECK{}, you cannot exit(0). You may exit !0, but not 0. > If you put this in /tmp/a and run it: > > #BEGIN { warn "testing exit from BEGIN"; exit } > #BEGIN { warn "testing exit N from BEGIN"; exit 1 } > > #INIT { warn "testing exit from INIT"; exit } > #INIT { warn "testing exit N from INIT"; exit 2 } > > CHECK { warn "testing exit from CHECK"; exit } > #CHECK { warn "testing exit N from CHECK"; exit 3 } > > #END { warn "testing exit from END"; exit } > #END { warn "testing exit N from END"; exit 4 } > > print "i am now the main program\n"; > warn "testing exit 5 from main"; > exit 5; > > die "XXX"; > > You will get: > > % perl /tmp/a > testing exit from CHECK at /tmp/a line 7. > i am now the main program > testing exit 5 from main at /tmp/a line 14. > Exit 5 > > If you switch the comment on the two CHECKs, you get > > % perl /tmp/a > testing exit N from CHECK at /tmp/a line 8. > Exit 3
The problem (as of today's Perl) is that perl_parse() returns the exit status as if it were going back to the OS. In main(), perl does: "exitstatus = perl_parse(...); if (!exitstatus) perl_run(...);' Which means main() can't tell the difference between normal execution (0 from JMPENV) and my_exit (2 from JMPENV) because the my_exit case sets the return value to the exit code (0). perl_parse() is flagged as public API so my patch below is unacceptable although it does fix the immediate problem. I include it more as illustration than for inclusion (which is why it is a 'diff', not a 'commit'). It does, however, pass all tests which makes me think there should be tests that the public API is stable. I appeal to greater powers for a "public API"-acceptable fix. :) -- George Greer
Download nak.patch
text/plain 767b
diff --git a/perl.c b/perl.c index 0edad78..8815ed1 100644 --- a/perl.c +++ b/perl.c @@ -1606,11 +1606,8 @@ perl_parse(pTHXx_ XSINIT_t xsinit, int argc, char **argv, char **env) call_list(oldscope, PL_unitcheckav); if (PL_checkav) call_list(oldscope, PL_checkav); - ret = 0; break; case 1: - STATUS_ALL_FAILURE; - /* FALL THROUGH */ case 2: /* my_exit() was called */ while (PL_scopestack_ix > oldscope) @@ -1621,11 +1618,9 @@ perl_parse(pTHXx_ XSINIT_t xsinit, int argc, char **argv, char **env) call_list(oldscope, PL_unitcheckav); if (PL_checkav) call_list(oldscope, PL_checkav); - ret = STATUS_EXIT; break; case 3: PerlIO_printf(Perl_error_log, "panic: top_env\n"); - ret = 1; break; } JMPENV_POP;
Subject: Automatic mail for tchrist [Re: [perl #2754] [PSEUDO-PATCH][BUG] can't exit 0 from CHECK{}]
Date: Sun, 11 Jul 2010 03:26:10 -0600 (MDT)
To: perlbug-followup [...] perl.org
From: Tom Christiansen <tchrist [...] perl.com>
Download (untitled) / with headers
text/plain 584b
+---------------------------------------------------------------------+ | This is automatic mail from Tom Christiansen's answering service. | | UPDATED: Saturday, 2010 July 10 18:01:10 MDT 2010 | +---------------------------------------------------------------------+ I'm away from the office, up in the Colorado wilderness, minimally until Wednesday, July 14th. I do *not* expect to have email or phone access while I'm away. I'll do my best to get back to you as soon as I return. --tom
RT-Send-CC: perl5-porters [...] perl.org
On Sun Jul 11 00:23:23 2010, greerga wrote: Show quoted text
> On Tue Mar 28 03:39:19 2000, tchrist@chthon.perl.com wrote:
> > From a CHECK{}, you cannot exit(0). You may exit !0, but not 0. > > If you put this in /tmp/a and run it: > > > > #BEGIN { warn "testing exit from BEGIN"; exit } > > #BEGIN { warn "testing exit N from BEGIN"; exit 1 } > > > > #INIT { warn "testing exit from INIT"; exit } > > #INIT { warn "testing exit N from INIT"; exit 2 } > > > > CHECK { warn "testing exit from CHECK"; exit } > > #CHECK { warn "testing exit N from CHECK"; exit 3 } > > > > #END { warn "testing exit from END"; exit } > > #END { warn "testing exit N from END"; exit 4 } > > > > print "i am now the main program\n"; > > warn "testing exit 5 from main"; > > exit 5; > > > > die "XXX"; > > > > You will get: > > > > % perl /tmp/a > > testing exit from CHECK at /tmp/a line 7. > > i am now the main program > > testing exit 5 from main at /tmp/a line 14. > > Exit 5 > > > > If you switch the comment on the two CHECKs, you get > > > > % perl /tmp/a > > testing exit N from CHECK at /tmp/a line 8. > > Exit 3
> > The problem (as of today's Perl) is that perl_parse() returns the exit > status as if it were going back to the OS. In main(), perl does: > "exitstatus = perl_parse(...); if (!exitstatus) perl_run(...);' Which > means main() can't tell the difference between normal execution (0 from > JMPENV) and my_exit (2 from JMPENV) because the my_exit case sets the > return value to the exit code (0). > > perl_parse() is flagged as public API so my patch below is unacceptable > although it does fix the immediate problem. I include it more as > illustration than for inclusion (which is why it is a 'diff', not a > 'commit'). It does, however, pass all tests which makes me think there > should be tests that the public API is stable. > > I appeal to greater powers for a "public API"-acceptable fix. :)
I reappeal to greater powers for a "public API"-acceptable fix. Would be nice to get this bug closed once and for all!
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 714b
On Fri May 04 12:15:22 2012, Hugmeir wrote: Show quoted text
> > I appeal to greater powers for a "public API"-acceptable fix. :)
> > I reappeal to greater powers for a "public API"-acceptable fix. Would be > nice to get this bug closed once and for all!
Hmm, does this actually break the contract of the public API? The docs that I've found don't specify any specific return values, they just show through example that: (From perlembed.pod) exitstatus = perl_parse(my_perl, NULL, 2, embedding, NULL); PL_exit_flags |= PERL_EXIT_DESTRUCT_END; if(!exitstatus) { exitstatus = perl_run(my_perl); So as long as perl_parse returns a false value when it succeeds, we should be good? -- Matthew Horsfall (alh)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 987b
On Sun Nov 25 05:31:01 2012, alh wrote: Show quoted text
> On Fri May 04 12:15:22 2012, Hugmeir wrote:
> > > I appeal to greater powers for a "public API"-acceptable fix. :)
> > > > I reappeal to greater powers for a "public API"-acceptable fix. Would be > > nice to get this bug closed once and for all!
> > Hmm, does this actually break the contract of the public API? > > The docs that I've found don't specify any specific return values, they > just show through example that: > > (From perlembed.pod) > exitstatus = perl_parse(my_perl, NULL, 2, embedding, NULL); > PL_exit_flags |= PERL_EXIT_DESTRUCT_END; > if(!exitstatus) { > exitstatus = perl_run(my_perl); > > So as long as perl_parse returns a false value when it succeeds, we > should be good?
I think we need to rethink (carefully!) how perl handles this internally. That BEGIN{exit 0} exits the program and CHECK{exit 0} does not seems like the implementation details leaking through. -- Father Chrysostomos
Date: Sun, 10 Dec 2017 22:17:02 +0000
To: perl5-porters [...] perl.org
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 1.5k
Oh boy, this was a fun one. The basic problem is that the return value from perl_parse() is overloaded. Is it a truth value or an exit code? If an exit code, is it a Unix-style exit code or a native exit code? The perlembed tutorial disagreed with perlmain.c and had a bunch of flaws that mark it as an unreliable source, and the function wasn't actually documented other than by reference to perlembed. We can preserve most of the overloaded use of perl_parse()'s return value by the very simple expedient of returning 0x100 for a zero exit code, leaving an actual zero return value to indicate that we're not exiting. On Unix this is a total fix. On other OSes an equivalent trick might be possible, but might not, depending on local conventions for exit codes. (It's clear enough that perl_parse()'s return value has the significance of a native exit code, despite the Unix-centric assumptions that crept in.) It should in any case return non-zero for a zero native exit code regardless of platform: that means that an exit with zero native exit code will at least always be interpreted as exiting, so the remaining misbehaviour will only consist of exiting with the wrong exit code. For users to get the correct exit code they need to interpret perl_parse()'s return value the way perlmain.c does: as a truth value, with the actual exit code coming from perl_destruct(). perlembed needs to show this mode of usage. I have done all this (and some more) in commit 0301e899536a22752f40481d8a1d141b7a7dda82. That resolves this ticket. -zefram
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
To: perl5-porters [...] perl.org
Date: Wed, 27 Dec 2017 21:26:46 +0000
Download (untitled) / with headers
text/plain 341b
In order to give Module::Install distros more time to roll out a fix for [perl #132577], this bug [perl #2754] has been reintroduced in commit 857320cbf85e762add18885ae8a197b5e0c21b69. This ticket should be reopened. The plan is to revert the bug reintroduction during the 5.29 development cycle. This issue should block 5.30.0. -zefram
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
To: perl5-porters [...] perl.org
Date: Wed, 27 Dec 2017 23:37:03 +0200
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 825b
Following this, we should formulate a plan for dealing with these distributions and having them release new versions. We have time but our goal is to still have this bug fix in the next version and this could only be done if we are able to have enough distributions released with the fix. Zefram, is it possible to provide a succinct way to explain this change to module authors when we submit patches or request the changes made? On 12/27/2017 11:26 PM, Zefram wrote: Show quoted text
> In order to give Module::Install distros more time to roll out a fix > for [perl #132577], this bug [perl #2754] has been reintroduced in > commit 857320cbf85e762add18885ae8a197b5e0c21b69. This ticket should > be reopened. The plan is to revert the bug reintroduction during the > 5.29 development cycle. This issue should block 5.30.0. > > -zefram
To: perl5-porters [...] perl.org
Date: Wed, 27 Dec 2017 21:46:56 +0000
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 425b
Sawyer X wrote: Show quoted text
>Zefram, is it possible to provide a succinct way to explain this change >to module authors when we submit patches or request the changes made?
"Module::Install::DSL versions below 1.19 rely on a core bug, and are going to stop working on Perl versions above 5.28. To keep your module installable on future Perls, please rerelease it with the bundled Module::Install::DSL updated to version 1.19." -zefram
Re-opening ticket per discussion. -- James E Keenan (jkeenan@cpan.org)
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
Date: Thu, 28 Dec 2017 12:19:53 -0800
CC: perl5-porters [...] perl.org
To: Zefram <zefram [...] fysh.org>
From: Karen Etheridge <perl [...] froods.org>
Download (untitled) / with headers
text/plain 826b
Use of Module::Install is discouraged by the Perl Toolchain Gang, and it may soon be formally deprecated. I would prefer the recommendation not simply suggest the author re-release with a newer MI, but rather convert their distribution off of MI entirely and therefore avoid all other issues arising from its use.

On Wed, Dec 27, 2017 at 1:46 PM, Zefram <zefram@fysh.org> wrote:
Show quoted text
Sawyer X wrote:
>Zefram, is it possible to provide a succinct way to explain this change
>to module authors when we submit patches or request the changes made?

"Module::Install::DSL versions below 1.19 rely on a core bug, and
are going to stop working on Perl versions above 5.28.  To keep your
module installable on future Perls, please rerelease it with the bundled
Module::Install::DSL updated to version 1.19."

-zefram

CC: perl5-porters [...] perl.org
To: Karen Etheridge <perl [...] froods.org>, Zefram <zefram [...] fysh.org>
Date: Thu, 28 Dec 2017 13:42:26 -0700
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 965b
On 12/28/2017 01:19 PM, Karen Etheridge wrote: Show quoted text
> Use of Module::Install is discouraged by the Perl Toolchain Gang, and it > may soon be formally deprecated. I would prefer the recommendation not > simply suggest the author re-release with a newer MI, but rather convert > their distribution off of MI entirely and therefore avoid all other > issues arising from its use.
+1 Show quoted text
> > On Wed, Dec 27, 2017 at 1:46 PM, Zefram <zefram@fysh.org > <mailto:zefram@fysh.org>> wrote: > > Sawyer X wrote:
> >Zefram, is it possible to provide a succinct way to explain this change > >to module authors when we submit patches or request the changes made?
> > "Module::Install::DSL versions below 1.19 rely on a core bug, and > are going to stop working on Perl versions above 5.28.  To keep your > module installable on future Perls, please rerelease it with the bundled > Module::Install::DSL updated to version 1.19." > > -zefram > >
From: Slaven Rezic <slaven [...] rezic.de>
CC: Zefram <zefram [...] fysh.org>, perl5-porters [...] perl.org
To: Karen Etheridge <perl [...] froods.org>
Date: Thu, 28 Dec 2017 21:43:14 +0100
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
Karen Etheridge <perl@froods.org> writes: Show quoted text
> Use of Module::Install is discouraged by the Perl Toolchain Gang, and it > may soon be formally deprecated.
Module::Install is used by several thousand CPAN distributions. A deprecation seems impractical. Show quoted text
> I would prefer the recommendation not > simply suggest the author re-release with a newer MI, but rather convert > their distribution off of MI entirely and therefore avoid all other issues > arising from its use. > > On Wed, Dec 27, 2017 at 1:46 PM, Zefram <zefram@fysh.org> wrote: >
>> Sawyer X wrote:
>> >Zefram, is it possible to provide a succinct way to explain this change >> >to module authors when we submit patches or request the changes made?
>> >> "Module::Install::DSL versions below 1.19 rely on a core bug, and >> are going to stop working on Perl versions above 5.28. To keep your >> module installable on future Perls, please rerelease it with the bundled >> Module::Install::DSL updated to version 1.19." >> >> -zefram >>
-- Slaven Rezic - slaven <at> rezic <dot> de Berlin Perl Mongers - http://berlin.pm.org
CC: Karen Etheridge <perl [...] froods.org>, Zefram <zefram [...] fysh.org>, Perl5 Porters <perl5-porters [...] perl.org>
To: Slaven Rezic <slaven [...] rezic.de>
Date: Thu, 28 Dec 2017 13:04:49 -0800
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
From: Karen Etheridge <perl [...] froods.org>
Download (untitled) / with headers
text/plain 2.1k
A module being deprecated doesn't mean it will be removed from cpan (unless that has been explicitly stated) -- rather it signals that it is no longer being actively maintained save for critical bug fixes, which is exactly the case here. Authors must be aware that it is no longer recommended, and if they are making a new release of their distribution, they are strongly encouraged to use something else than Module::Install.

We already have a breakage with Module::Install since 5.26 (unless PERL_USE_UNSAFE_INC is set), which will necessitate re-release of MI-using distributions before 5.30; the Module::Install::DSL failure with INIT blocks is just one more nail in its coffin.  The sad and unavoidable fact is that MI's practice of bundling its code into the distribution itself (rather than falling back to the latest cpan release via configure-requires) will continue to cause issues for all distributions that use it.


On Thu, Dec 28, 2017 at 12:43 PM, Slaven Rezic <slaven@rezic.de> wrote:
Show quoted text
Karen Etheridge <perl@froods.org> writes:

> Use of Module::Install is discouraged by the Perl Toolchain Gang, and it
> may soon be formally deprecated.

Module::Install is used by several thousand CPAN distributions. A
deprecation seems impractical.

> I would prefer the recommendation not
> simply suggest the author re-release with a newer MI, but rather convert
> their distribution off of MI entirely and therefore avoid all other issues
> arising from its use.
>
> On Wed, Dec 27, 2017 at 1:46 PM, Zefram <zefram@fysh.org> wrote:
>
>> Sawyer X wrote:
>> >Zefram, is it possible to provide a succinct way to explain this change
>> >to module authors when we submit patches or request the changes made?
>>
>> "Module::Install::DSL versions below 1.19 rely on a core bug, and
>> are going to stop working on Perl versions above 5.28.  To keep your
>> module installable on future Perls, please rerelease it with the bundled
>> Module::Install::DSL updated to version 1.19."
>>
>> -zefram
>>

--
Slaven Rezic - slaven <at> rezic <dot> de

    Berlin Perl Mongers - http://berlin.pm.org


RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Thu, 28 Dec 2017 13:05:10 -0800, perl@froods.org wrote: Show quoted text
> On Thu, Dec 28, 2017 at 12:43 PM, Slaven Rezic <slaven@rezic.de> > wrote: >
> > Karen Etheridge <perl@froods.org> writes: > >
> > > Use of Module::Install is discouraged by the Perl Toolchain Gang, > > > and it > > > may soon be formally deprecated.
> > > > Module::Install is used by several thousand CPAN distributions. A > > deprecation seems impractical. > >
> A module being deprecated doesn't mean it will be removed from cpan > (unless > that has been explicitly stated) -- rather it signals that it is no > longer > being actively maintained save for critical bug fixes, which is > exactly the > case here. Authors must be aware that it is no longer recommended, and > if > they are making a new release of their distribution, they are strongly > encouraged to use something else than Module::Install. > > We already have a breakage with Module::Install since 5.26 (unless > PERL_USE_UNSAFE_INC is set), which will necessitate re-release of MI- > using > distributions before 5.30; the Module::Install::DSL failure with INIT > blocks is just one more nail in its coffin. The sad and unavoidable > fact > is that MI's practice of bundling its code into the distribution > itself > (rather than falling back to the latest cpan release via > configure-requires) will continue to cause issues for all > distributions > that use it.
But that is also the reason why deprecating the newest, fixed version of Module::Install is not an immediate problem for those several thousand distributions. They are not using it yet. -- Father Chrysostomos
CC: Perl5 Porters <perl5-porters [...] perl.org>
To: Dave Mitchell via RT <perlbug-followup [...] perl.org>
Date: Thu, 28 Dec 2017 16:53:00 -0500
Subject: Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
From: Dan Book <grinnz [...] gmail.com>
Download (untitled) / with headers
text/plain 662b
On Thu, Dec 28, 2017 at 4:43 PM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote: Show quoted text

But that is also the reason why deprecating the newest, fixed version of Module::Install is not an immediate problem for those several thousand distributions.  They are not using it yet.

In this case, the main benefit of deprecation is forceful documentation that people should really stop using it and switch away from it when possible. This is a benefit because its bundling nature means future breakage can only be truly resolved, as in this case, by rereleasing all affected modules, which is largely impractical for any more widespread issue.

-Dan 
RT-Send-CC: perl5-porters [...] perl.org
On Thu, 28 Dec 2017 21:05:10 GMT, perl@froods.org wrote: Show quoted text
> A module being deprecated doesn't mean it will be removed from cpan > (unless > that has been explicitly stated) -- rather it signals that it is no > longer > being actively maintained save for critical bug fixes, which is > exactly the > case here. Authors must be aware that it is no longer recommended, and > if > they are making a new release of their distribution, they are strongly > encouraged to use something else than Module::Install. > > We already have a breakage with Module::Install since 5.26 (unless > PERL_USE_UNSAFE_INC is set), which will necessitate re-release of MI- > using > distributions before 5.30; the Module::Install::DSL failure with INIT > blocks is just one more nail in its coffin. The sad and unavoidable > fact > is that MI's practice of bundling its code into the distribution > itself > (rather than falling back to the latest cpan release via > configure-requires) will continue to cause issues for all > distributions > that use it. > >
+1 -- James E Keenan (jkeenan@cpan.org)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org