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

Owner: Nobody
Requestors: zefram [at] fysh.org
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: High
Type:
Perl Version: 5.27.7
Fixed In: (no value)



Subject: BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: zefram [...] fysh.org
To: perlbug [...] perl.org
CC: zefram [...] fysh.org
Date: Tue, 12 Dec 2017 18:18:53 +0000
Download (untitled) / with headers
text/plain 3.8k
This is a bug report for perl from zefram@fysh.org, generated with the help of perlbug 1.41 running under perl 5.27.7. ----------------------------------------------------------------- [Please describe your issue here] Module::Install fails one of its tests since core commit 0301e899536a22752f40481d8a1d141b7a7dda82 "properly define perl_parse() return value". I'm surprised that anything noticed such small code changes. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=high --- Site configuration information for perl 5.27.7: Configured by zefram at Tue Dec 12 12:07:39 GMT 2017. Summary of my perl5 (revision 5 version 27 subversion 7) configuration: Commit id: 0301e899536a22752f40481d8a1d141b7a7dda82 Platform: osname=linux osvers=3.16.0-4-amd64 archname=x86_64-linux-thread-multi uname='linux barba.rous.org 3.16.0-4-amd64 #1 smp debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 gnulinux ' config_args='-des -Dprefix=/home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52 -Duselargefiles -Dusethreads -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dusedevel -Uversiononly -Ui_db -DDEBUGGING' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2' optimize='-O2 -g' cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='4.9.2' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='cc' ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.19.so so=so useshrplib=true libperl=libperl.so gnulibc_version='2.19' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,-E -Wl,-rpath,/home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/5.27.7/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC' lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector-strong' --- @INC for perl 5.27.7: /home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/site_perl/5.27.7/x86_64-linux-thread-multi /home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/site_perl/5.27.7 /home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/5.27.7/x86_64-linux-thread-multi /home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/lib/5.27.7 --- Environment for perl 5.27.7: HOME=/home/zefram LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/zefram/usr/perl/perl_install/perl-git-blead-i64-f52/bin:/home/zefram/pub/x86_64-unknown-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/bin:/usr/local/bin:/usr/games PERL5LIB= PERL5OPT= PERL5_CPANPLUS_IS_RUNNING=13467 PERL5_CPAN_IS_RUNNING=13467 PERLDOC=-oman PERL_BADLANG (unset) SHELL=/usr/bin/zsh
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: Zefram <zefram [...] fysh.org>
Date: Tue, 12 Dec 2017 19:13:36 +0000
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.1k
I wrote: Show quoted text
>Module::Install fails one of its tests since core commit >0301e899536a22752f40481d8a1d141b7a7dda82 "properly define perl_parse() >return value".
Turns out that Module::Install::DSL has some rather convoluted code in which an "import" method that runs from a Makefile.PL establishes an INIT block that will do the real work of Makefile.PL and then performs exit(0). The behaviour difference that's relevant boils down to: $ perl5.27.6 -lwe 'print "main program"; INIT { print "init block"; } BEGIN { print "begin block"; exit 0; }' begin block init block $ perl-blead -lwe 'print "main program"; INIT { print "init block"; } BEGIN { print "begin block"; exit 0; }' begin block $ That is, after a BEGIN block performs an exit(0), perl used to run INIT blocks and then exit, but now it exits immediately without running INIT blocks. It always used to exit without running INIT blocks upon an exit with non-zero exit code, or upon an exception. This situation is not precisely the exit(0) from a CHECK block that was called out in [perl #2754], and indeed on that ticket it was thought that exit(0) from BEGIN blocks was operating correctly. Nevertheless, for it to execute BEGIN blocks is clearly another form of the same bug with which that ticket is concerned, and the commit has fixed it. Module::Install::DSL does have a genuine, if not entirely respectable, reason for its exit(0). The essence of this module is that a Makefile.PL invokes the module and then stops containing Perl code, instead switching to a DSL to specify attributes of its distro. The module opens up the Makefile.PL as a file to read it in and parse this DSL, and uses exit(0) to prevent Perl's parsing of the top-level Makefile.PL from proceeding into the DSL code that would constitute syntax errors. However, as far as I can see there's no need at all for the module to delay execution of the code it generates by putting it in an INIT block. If that code is instead executed immediately, by deleting the word "INIT" to turn it into a bare block, everything works. With that alteration to the module, the Module-Install distro passes its test suite. -zefram
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: Zefram <zefram [...] fysh.org>
To: perl5-porters [...] perl.org
Date: Tue, 12 Dec 2017 19:21:53 +0000
I have opened [rt.cpan.org #123867] on the Module-Install side. -zefram
From: Leon Timmermans <fawaka [...] gmail.com>
Date: Tue, 12 Dec 2017 23:03:11 +0100
To: Zefram <zefram [...] fysh.org>
CC: Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
Download (untitled) / with headers
text/plain 608b
On Tue, Dec 12, 2017 at 8:13 PM, Zefram <zefram@fysh.org> wrote:
Show quoted text
However, as far as I can see there's no need at all for the module to
delay execution of the code it generates by putting it in an INIT block.
If that code is instead executed immediately, by deleting the word "INIT"
to turn it into a bare block, everything works.  With that alteration
to the module, the Module-Install distro passes its test suite.

Given Module::Install's rather unfortunate bundling nature, that would require rereleasing all 119 distributions using it to be rereleased with such a new Module::Install.

Leon
From: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
To: Zefram <zefram [...] fysh.org>
CC: Perl5 Porters <perl5-porters [...] perl.org>
Date: Tue, 12 Dec 2017 23:04:23 +0100
Download (untitled) / with headers
text/plain 809b
On Tue, Dec 12, 2017 at 11:03 PM, Leon Timmermans <fawaka@gmail.com> wrote:
Show quoted text
On Tue, Dec 12, 2017 at 8:13 PM, Zefram <zefram@fysh.org> wrote:
However, as far as I can see there's no need at all for the module to
delay execution of the code it generates by putting it in an INIT block.
If that code is instead executed immediately, by deleting the word "INIT"
to turn it into a bare block, everything works.  With that alteration
to the module, the Module-Install distro passes its test suite.

Given Module::Install's rather unfortunate bundling nature, that would require rereleasing all 119 distributions using it to be rereleased with such a new Module::Install.

Well, all 119 modules using Module::Install::DSL, Module::Install in general has quite a few more users.

Leon

Date: Sun, 17 Dec 2017 13:05:20 +0200
To: perl5-porters [...] perl.org
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: Sawyer X <xsawyerx [...] gmail.com>
On 12/13/2017 12:04 AM, Leon Timmermans wrote: Show quoted text
> On Tue, Dec 12, 2017 at 11:03 PM, Leon Timmermans <fawaka@gmail.com > <mailto:fawaka@gmail.com>> wrote: > > On Tue, Dec 12, 2017 at 8:13 PM, Zefram <zefram@fysh.org > <mailto:zefram@fysh.org>> wrote: > > However, as far as I can see there's no need at all for the > module to > delay execution of the code it generates by putting it in an > INIT block. > If that code is instead executed immediately, by deleting the > word "INIT" > to turn it into a bare block, everything works.  With that > alteration > to the module, the Module-Install distro passes its test suite. > > > Given Module::Install's rather unfortunate bundling nature, that > would require rereleasing all 119 distributions using it to be > rereleased with such a new Module::Install. > > > Well, all 119 modules using Module::Install::DSL, Module::Install in > general has quite a few more users.
That is indeed a pain. What is the cost of reverting this commit instead?
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
On Sun, 17 Dec 2017 03:06:01 -0800, xsawyerx@gmail.com wrote: Show quoted text
> > > On 12/13/2017 12:04 AM, Leon Timmermans wrote:
> > On Tue, Dec 12, 2017 at 11:03 PM, Leon Timmermans <fawaka@gmail.com > > <mailto:fawaka@gmail.com>> wrote: > > > > On Tue, Dec 12, 2017 at 8:13 PM, Zefram <zefram@fysh.org > > <mailto:zefram@fysh.org>> wrote: > > > > However, as far as I can see there's no need at all for the > > module to > > delay execution of the code it generates by putting it in an > > INIT block. > > If that code is instead executed immediately, by deleting the > > word "INIT" > > to turn it into a bare block, everything works.  With that > > alteration > > to the module, the Module-Install distro passes its test suite. > > > > > > Given Module::Install's rather unfortunate bundling nature, that > > would require rereleasing all 119 distributions using it to be > > rereleased with such a new Module::Install. > > > > > > Well, all 119 modules using Module::Install::DSL, Module::Install in > > general has quite a few more users.
> > That is indeed a pain.
I seem to remember an old blog or list post by Michael Schwern predicting this very problem with Module::Install. Show quoted text
> What is the cost of reverting this commit instead?
Buggy, unpredictable behaviour, unless you can memorise the list of complex rules for when exit does and does not prevent other blocks from running. -- Father Chrysostomos
Date: Mon, 18 Dec 2017 17:39:14 +0200
CC: perl5-porters [...] perl.org
To: perlbug-followup [...] perl.org
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 1.5k
On 12/17/2017 09:17 PM, Father Chrysostomos via RT wrote: Show quoted text
> On Sun, 17 Dec 2017 03:06:01 -0800, xsawyerx@gmail.com wrote:
>> >> On 12/13/2017 12:04 AM, Leon Timmermans wrote:
>>> On Tue, Dec 12, 2017 at 11:03 PM, Leon Timmermans <fawaka@gmail.com >>> <mailto:fawaka@gmail.com>> wrote: >>> >>> On Tue, Dec 12, 2017 at 8:13 PM, Zefram <zefram@fysh.org >>> <mailto:zefram@fysh.org>> wrote: >>> >>> However, as far as I can see there's no need at all for the >>> module to >>> delay execution of the code it generates by putting it in an >>> INIT block. >>> If that code is instead executed immediately, by deleting the >>> word "INIT" >>> to turn it into a bare block, everything works.  With that >>> alteration >>> to the module, the Module-Install distro passes its test suite. >>> >>> >>> Given Module::Install's rather unfortunate bundling nature, that >>> would require rereleasing all 119 distributions using it to be >>> rereleased with such a new Module::Install. >>> >>> >>> Well, all 119 modules using Module::Install::DSL, Module::Install in >>> general has quite a few more users.
>> That is indeed a pain.
> I seem to remember an old blog or list post by Michael Schwern predicting this very problem with Module::Install. >
>> What is the cost of reverting this commit instead?
> Buggy, unpredictable behaviour, unless you can memorise the list of complex rules for when exit does and does not prevent other blocks from running.
Are you referring to long-term or immediate effect? I'm wondering about temporary revert.
RT-Send-CC: perl5-porters [...] perl.org
On Mon, 18 Dec 2017 07:39:32 -0800, xsawyerx@gmail.com wrote: Show quoted text
> > > On 12/17/2017 09:17 PM, Father Chrysostomos via RT wrote:
> > On Sun, 17 Dec 2017 03:06:01 -0800, xsawyerx@gmail.com wrote:
> >> > >> On 12/13/2017 12:04 AM, Leon Timmermans wrote:
> >>> On Tue, Dec 12, 2017 at 11:03 PM, Leon Timmermans <fawaka@gmail.com > >>> <mailto:fawaka@gmail.com>> wrote: > >>> > >>> On Tue, Dec 12, 2017 at 8:13 PM, Zefram <zefram@fysh.org > >>> <mailto:zefram@fysh.org>> wrote: > >>> > >>> However, as far as I can see there's no need at all for the > >>> module to > >>> delay execution of the code it generates by putting it in an > >>> INIT block. > >>> If that code is instead executed immediately, by deleting the > >>> word "INIT" > >>> to turn it into a bare block, everything works.  With that > >>> alteration > >>> to the module, the Module-Install distro passes its test suite. > >>> > >>> > >>> Given Module::Install's rather unfortunate bundling nature, that > >>> would require rereleasing all 119 distributions using it to be > >>> rereleased with such a new Module::Install. > >>> > >>> > >>> Well, all 119 modules using Module::Install::DSL, Module::Install > >>> in > >>> general has quite a few more users.
> >> That is indeed a pain.
> > I seem to remember an old blog or list post by Michael Schwern > > predicting this very problem with Module::Install. > >
> >> What is the cost of reverting this commit instead?
> > Buggy, unpredictable behaviour, unless you can memorise the list of > > complex rules for when exit does and does not prevent other blocks > > from running.
> > Are you referring to long-term or immediate effect?
I’m referring to the bugs that Zefram fixed, which went even deeper than Zefram realized when he was fixing them. So at present nobody but he can predict which blocks will trigger at what time if ‘exit’ is used in them. Show quoted text
> I'm wondering about temporary revert.
That might be a good approach: revert and then reinstate after 5.28. In the mean time, a bunch of modules need to be released. -- Father Chrysostomos
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
Date: Tue, 19 Dec 2017 17:34:49 +0200
To: perl5-porters [...] perl.org
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 2.2k
On 12/18/2017 07:39 PM, Father Chrysostomos via RT wrote: Show quoted text
> On Mon, 18 Dec 2017 07:39:32 -0800, xsawyerx@gmail.com wrote:
>> >> On 12/17/2017 09:17 PM, Father Chrysostomos via RT wrote:
>>> On Sun, 17 Dec 2017 03:06:01 -0800, xsawyerx@gmail.com wrote:
>>>> On 12/13/2017 12:04 AM, Leon Timmermans wrote:
>>>>> On Tue, Dec 12, 2017 at 11:03 PM, Leon Timmermans <fawaka@gmail.com >>>>> <mailto:fawaka@gmail.com>> wrote: >>>>> >>>>> On Tue, Dec 12, 2017 at 8:13 PM, Zefram <zefram@fysh.org >>>>> <mailto:zefram@fysh.org>> wrote: >>>>> >>>>> However, as far as I can see there's no need at all for the >>>>> module to >>>>> delay execution of the code it generates by putting it in an >>>>> INIT block. >>>>> If that code is instead executed immediately, by deleting the >>>>> word "INIT" >>>>> to turn it into a bare block, everything works.  With that >>>>> alteration >>>>> to the module, the Module-Install distro passes its test suite. >>>>> >>>>> >>>>> Given Module::Install's rather unfortunate bundling nature, that >>>>> would require rereleasing all 119 distributions using it to be >>>>> rereleased with such a new Module::Install. >>>>> >>>>> >>>>> Well, all 119 modules using Module::Install::DSL, Module::Install >>>>> in >>>>> general has quite a few more users.
>>>> That is indeed a pain.
>>> I seem to remember an old blog or list post by Michael Schwern >>> predicting this very problem with Module::Install. >>>
>>>> What is the cost of reverting this commit instead?
>>> Buggy, unpredictable behaviour, unless you can memorise the list of >>> complex rules for when exit does and does not prevent other blocks >>> from running.
>> Are you referring to long-term or immediate effect?
> I’m referring to the bugs that Zefram fixed, which went even deeper than Zefram realized when he was fixing them. So at present nobody but he can predict which blocks will trigger at what time if ‘exit’ is used in them. >
>> I'm wondering about temporary revert.
> That might be a good approach: revert and then reinstate after 5.28. In the mean time, a bunch of modules need to be released.
Exactly. A better phrasing for my question is "How problematic would it be to postpone this fix to after 5.28 so we could fix the modules and release?" Zefram, can you please weigh in here?
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: Zefram <zefram [...] fysh.org>
Date: Fri, 22 Dec 2017 07:02:52 +0000
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 550b
Sawyer X wrote: Show quoted text
>Exactly. A better phrasing for my question is "How problematic would it >be to postpone this fix to after 5.28 so we could fix the modules and >release?"
The impact of retaining the bug for another year should be low. It's a long-standing bug, with fairly obscure triggering conditions. There's little internally that depends on the bug being fixed; only the documentation would have to change to match. If there's a significant win to be made in CPAN readiness for the fix then it would be a reasonable course of action. -zefram
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 188b
On Thu, 21 Dec 2017 23:03:05 -0800, zefram@fysh.org wrote: Show quoted text
> If there's a significant win to be made in CPAN readiness for the fix...
Is kicking the can down the road a significant win?
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
CC: perl5-porters [...] perl.org, Slaven Rezic <srezic [...] cpan.org>
To: Zefram <zefram [...] fysh.org>
Date: Sat, 23 Dec 2017 15:13:10 +0100
Also affected (discovered by Slaven): MANWAR/Test-Strict-0.40.tar.gz -- andreas
Date: Sun, 24 Dec 2017 20:10:43 +0200
To: perl5-porters [...] perl.org
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: Sawyer X <xsawyerx [...] gmail.com>
Download (untitled) / with headers
text/plain 530b
On 12/22/2017 09:02 AM, Zefram wrote: Show quoted text
> Sawyer X wrote:
>> Exactly. A better phrasing for my question is "How problematic would it >> be to postpone this fix to after 5.28 so we could fix the modules and >> release?"
> [...] If there's a significant > win to be made in CPAN readiness for the fix then it would be a reasonable > course of action.
I'm not sure there is such readiness. We are fairly behind. Considering this fix is for such a long-standing low-priority bug, perhaps we could provide temporary warning for now?
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
To: perl5-porters [...] perl.org
Date: Mon, 25 Dec 2017 08:29:36 +0000
Download (untitled) / with headers
text/plain 866b
Sawyer X wrote: Show quoted text
>perhaps we could provide temporary warning for now?
You mean... a deprecation warning? Technically, if we revert perl_parse() to return zero for exit(0), it is feasible for this to detect that perl_run() would do something if called, and thus to warn that this bogus zero return matters. Thus using an early exit(0) with the intent that INIT blocks or the main program subsequently run could be deprecated. It's not feasible to do the same for perl_run() bogusly returning zero, or for perl_parse() bogusly returning zero when the subsequent use the caller makes of the interpreter would be something other than just calling perl_run(). But we haven't seen any breakage of those kinds (yet). For the purposes of pure Perl code such as Module::Install, as opposed to arbitrary C level embeddings, the feasible deprecation is sufficient. -zefram
From: Sawyer X <xsawyerx [...] gmail.com>
To: perl5-porters [...] perl.org
Date: Mon, 25 Dec 2017 12:46:28 +0200
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
Download (untitled) / with headers
text/plain 1.1k
On 12/25/2017 10:29 AM, Zefram wrote: Show quoted text
> Sawyer X wrote:
>> perhaps we could provide temporary warning for now?
> You mean... a deprecation warning?
Yes. Show quoted text
> Technically, if we revert perl_parse() to return zero for exit(0), > it is feasible for this to detect that perl_run() would do something > if called, and thus to warn that this bogus zero return matters. > Thus using an early exit(0) with the intent that INIT blocks or the main > program subsequently run could be deprecated. It's not feasible to do > the same for perl_run() bogusly returning zero, or for perl_parse() > bogusly returning zero when the subsequent use the caller makes of > the interpreter would be something other than just calling perl_run(). > But we haven't seen any breakage of those kinds (yet). For the purposes > of pure Perl code such as Module::Install, as opposed to arbitrary C > level embeddings, the feasible deprecation is sufficient.
Wherever we can warn here instead of die, it is better. Where we cannot, we already have a large enough list of breakages to churn through. We could try again later when the list has been reduced.
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
To: perl5-porters [...] perl.org
Date: Wed, 27 Dec 2017 21:23:52 +0000
Download (untitled) / with headers
text/plain 977b
Following discussion with Sawyer, where he determined that there is a need for more time to fix Module::Install distros, I have reintroduced the perl_parse() exit(0) bug in commit 857320cbf85e762add18885ae8a197b5e0c21b69. I tried adding a deprecation warning, but this turned out to cause noise. There's an INIT block buried deep inside Test::More, so the warning would fire for any test script that loaded Test::More and then did a skip_all in a BEGIN block, which is quite a common pattern. The logic around this INIT block doesn't really care whether it runs in this case, so there's nothing to fix. Rather than get these false warnings, Sawyer decided it was better to have no deprecation warning. We expect to fix the bug again during the 5.29 cycle. This would consist of reverting most of commit 857320cbf85e762add18885ae8a197b5e0c21b69: the documentation and code changes in perl.c, and the test changes in t/op/blocks.t. This issue should block 5.30.0. -zefram
Date: Thu, 19 Apr 2018 23:36:16 +0100
To: Zefram <zefram [...] fysh.org>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 1.2k
On Wed, Dec 27, 2017 at 09:23:52PM +0000, Zefram wrote: Show quoted text
> Following discussion with Sawyer, where he determined that > there is a need for more time to fix Module::Install distros, > I have reintroduced the perl_parse() exit(0) bug in commit > 857320cbf85e762add18885ae8a197b5e0c21b69. > > I tried adding a deprecation warning, but this turned out to cause noise. > There's an INIT block buried deep inside Test::More, so the warning > would fire for any test script that loaded Test::More and then did a > skip_all in a BEGIN block, which is quite a common pattern. The logic > around this INIT block doesn't really care whether it runs in this case, > so there's nothing to fix. Rather than get these false warnings, Sawyer > decided it was better to have no deprecation warning. > > We expect to fix the bug again during the 5.29 cycle. This would consist > of reverting most of commit 857320cbf85e762add18885ae8a197b5e0c21b69: > the documentation and code changes in perl.c, and the test changes in > t/op/blocks.t. This issue should block 5.30.0.
Since this change has been reverted for 5.28, I presume I can remove this ticket from the 5.28 blockers list. -- If life gives you lemons, you'll probably develop a citric acid allergy.
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
CC: perl5-porters [...] perl.org
To: Dave Mitchell <davem [...] iabyn.com>, Zefram <zefram [...] fysh.org>
Date: Fri, 20 Apr 2018 12:54:06 +0200
Download (untitled) / with headers
text/plain 1.2k
On 04/20/2018 12:36 AM, Dave Mitchell wrote: Show quoted text
> On Wed, Dec 27, 2017 at 09:23:52PM +0000, Zefram wrote:
>> Following discussion with Sawyer, where he determined that >> there is a need for more time to fix Module::Install distros, >> I have reintroduced the perl_parse() exit(0) bug in commit >> 857320cbf85e762add18885ae8a197b5e0c21b69. >> >> I tried adding a deprecation warning, but this turned out to cause noise. >> There's an INIT block buried deep inside Test::More, so the warning >> would fire for any test script that loaded Test::More and then did a >> skip_all in a BEGIN block, which is quite a common pattern. The logic >> around this INIT block doesn't really care whether it runs in this case, >> so there's nothing to fix. Rather than get these false warnings, Sawyer >> decided it was better to have no deprecation warning. >> >> We expect to fix the bug again during the 5.29 cycle. This would consist >> of reverting most of commit 857320cbf85e762add18885ae8a197b5e0c21b69: >> the documentation and code changes in perl.c, and the test changes in >> t/op/blocks.t. This issue should block 5.30.0.
> Since this change has been reverted for 5.28, I presume I can remove this > ticket from the 5.28 blockers list.
Yup.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
On Fri, 20 Apr 2018 03:54:26 -0700, xsawyerx@gmail.com wrote: Show quoted text
> > > On 04/20/2018 12:36 AM, Dave Mitchell wrote:
> > On Wed, Dec 27, 2017 at 09:23:52PM +0000, Zefram wrote:
> >> Following discussion with Sawyer, where he determined that > >> there is a need for more time to fix Module::Install distros, > >> I have reintroduced the perl_parse() exit(0) bug in commit > >> 857320cbf85e762add18885ae8a197b5e0c21b69. > >> > >> I tried adding a deprecation warning, but this turned out to cause noise. > >> There's an INIT block buried deep inside Test::More, so the warning > >> would fire for any test script that loaded Test::More and then did a > >> skip_all in a BEGIN block, which is quite a common pattern. The logic > >> around this INIT block doesn't really care whether it runs in this case, > >> so there's nothing to fix. Rather than get these false warnings, Sawyer > >> decided it was better to have no deprecation warning. > >> > >> We expect to fix the bug again during the 5.29 cycle. This would consist > >> of reverting most of commit 857320cbf85e762add18885ae8a197b5e0c21b69: > >> the documentation and code changes in perl.c, and the test changes in > >> t/op/blocks.t. This issue should block 5.30.0.
> > Since this change has been reverted for 5.28, I presume I can remove this > > ticket from the 5.28 blockers list.
> > Yup.
Pinging this ticket -- Karl Williamson
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 382b
On Thu, 28 Mar 2019 19:33:04 -0700, khw wrote: Show quoted text
> Pinging this ticket
I've been re-releasing all the modules I am aware of (that I have the ability to) that use Module::Install::DSL; I think the upper portions of the cpan river are now clean. Are we able to assess the remaining impact to the river, and perhaps establish the final list of distributions that are still of concern?
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
On Sat, 30 Mar 2019 03:54:10 GMT, ether wrote: Show quoted text
> On Thu, 28 Mar 2019 19:33:04 -0700, khw wrote: >
> > Pinging this ticket
> > > I've been re-releasing all the modules I am aware of (that I have the > ability to) that use Module::Install::DSL; I think the upper portions > of the cpan river are now clean. Are we able to assess the remaining > impact to the river, and perhaps establish the final list of > distributions that are still of concern?
For what it's worth ... I went to this (possibly inaccurate) list of CPAN distributions which are dependent upon Module::Install: http://deps.cpantesters.org/depended-on-by.pl?dist=Module-Install I extracted the 127 top-level distros, then excluded all distros beginning with Acme, Bundle or Task. That left 114 distros, which I attempted to install against Perl 5 blead (commit 930ded654, Apr 2 2019) on FreeBSD-11.2 (threaded) using cpanm as the installer. (I.e., the same approach I take toward monthly testing of the "CPAN-River-3000".) Certain modules failed to install for reasons that were expected given that they, or their prerequisites, do not get a PASS grade during the monthly CPAN-River-3000 process. Other modules failed to install because of upstream breakage in blead. However, I couldn't identify any distributions which failed due to Module::Install itself. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
From: Sawyer X <xsawyerx [...] gmail.com>
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
To: perlbug-followup [...] perl.org
CC: perl5-porters [...] perl.org
Date: Sun, 7 Apr 2019 08:43:53 +0300
On 4/3/19 2:53 PM, James E Keenan via RT wrote: Show quoted text
> On Sat, 30 Mar 2019 03:54:10 GMT, ether wrote:
>> On Thu, 28 Mar 2019 19:33:04 -0700, khw wrote: >>
>>> Pinging this ticket
>> >> I've been re-releasing all the modules I am aware of (that I have the >> ability to) that use Module::Install::DSL; I think the upper portions >> of the cpan river are now clean. Are we able to assess the remaining >> impact to the river, and perhaps establish the final list of >> distributions that are still of concern?
> For what it's worth ... > > I went to this (possibly inaccurate) list of CPAN distributions which are dependent upon Module::Install: > > http://deps.cpantesters.org/depended-on-by.pl?dist=Module-Install > > I extracted the 127 top-level distros, then excluded all distros beginning with Acme, Bundle or Task. That left 114 distros, which I attempted to install against Perl 5 blead (commit 930ded654, Apr 2 2019) on FreeBSD-11.2 (threaded) using cpanm as the installer. (I.e., the same approach I take toward monthly testing of the "CPAN-River-3000".)
Can you share this list, please?
Date: Sun, 7 Apr 2019 19:20:17 -0400
To: perl5-porters [...] perl.org
Subject: Re: [perl #132577] BBC Module::Install broken by0301e899536a22752f40481d8a1d141b7a7dda82
From: James E Keenan <jkeenan [...] pobox.com>
Download (untitled) / with headers
text/plain 1.1k
On 4/7/19 1:43 AM, Sawyer X wrote: Show quoted text
> > On 4/3/19 2:53 PM, James E Keenan via RT wrote:
>> On Sat, 30 Mar 2019 03:54:10 GMT, ether wrote:
>>> On Thu, 28 Mar 2019 19:33:04 -0700, khw wrote: >>>
>>>> Pinging this ticket
>>> >>> I've been re-releasing all the modules I am aware of (that I have the >>> ability to) that use Module::Install::DSL; I think the upper portions >>> of the cpan river are now clean. Are we able to assess the remaining >>> impact to the river, and perhaps establish the final list of >>> distributions that are still of concern?
>> For what it's worth ... >> >> I went to this (possibly inaccurate) list of CPAN distributions which are dependent upon Module::Install: >> >> http://deps.cpantesters.org/depended-on-by.pl?dist=Module-Install >> >> I extracted the 127 top-level distros, then excluded all distros beginning with Acme, Bundle or Task. That left 114 distros, which I attempted to install against Perl 5 blead (commit 930ded654, Apr 2 2019) on FreeBSD-11.2 (threaded) using cpanm as the installer. (I.e., the same approach I take toward monthly testing of the "CPAN-River-3000".)
> > > Can you share this list, please? >
Attached.

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Wed, 03 Apr 2019 11:53:39 GMT, jkeenan wrote: Show quoted text
> On Sat, 30 Mar 2019 03:54:10 GMT, ether wrote:
> > On Thu, 28 Mar 2019 19:33:04 -0700, khw wrote: > >
> > > Pinging this ticket
> > > > > > I've been re-releasing all the modules I am aware of (that I have the > > ability to) that use Module::Install::DSL; I think the upper portions > > of the cpan river are now clean. Are we able to assess the remaining > > impact to the river, and perhaps establish the final list of > > distributions that are still of concern?
> > For what it's worth ... > > I went to this (possibly inaccurate) list of CPAN distributions which > are dependent upon Module::Install: > > http://deps.cpantesters.org/depended-on-by.pl?dist=Module-Install > > I extracted the 127 top-level distros, then excluded all distros > beginning with Acme, Bundle or Task. That left 114 distros, which I > attempted to install against Perl 5 blead (commit 930ded654, Apr 2 > 2019) on FreeBSD-11.2 (threaded) using cpanm as the installer. (I.e., > the same approach I take toward monthly testing of the "CPAN-River- > 3000".) > > Certain modules failed to install for reasons that were expected given > that they, or their prerequisites, do not get a PASS grade during the > monthly CPAN-River-3000 process. Other modules failed to install > because of upstream breakage in blead. However, I couldn't identify > any distributions which failed due to Module::Install itself. > > Thank you very much.
CPANtesters currently all green for this distro. http://matrix.cpantesters.org/?dist=Module-Install;perl=5.29.10;reports=1 Can this ticket be marked Resolved? Thank you very much. -- James E Keenan (jkeenan@cpan.org)
CC: perl5-porters [...] perl.org
Date: Tue, 23 Apr 2019 16:03:22 +0100
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #132577] BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 2.1k
On Sat, Apr 13, 2019 at 07:02:10PM -0700, James E Keenan via RT wrote: Show quoted text
> On Wed, 03 Apr 2019 11:53:39 GMT, jkeenan wrote:
> > On Sat, 30 Mar 2019 03:54:10 GMT, ether wrote:
> > > On Thu, 28 Mar 2019 19:33:04 -0700, khw wrote: > > >
> > > > Pinging this ticket
> > > > > > > > > I've been re-releasing all the modules I am aware of (that I have the > > > ability to) that use Module::Install::DSL; I think the upper portions > > > of the cpan river are now clean. Are we able to assess the remaining > > > impact to the river, and perhaps establish the final list of > > > distributions that are still of concern?
> > > > For what it's worth ... > > > > I went to this (possibly inaccurate) list of CPAN distributions which > > are dependent upon Module::Install: > > > > http://deps.cpantesters.org/depended-on-by.pl?dist=Module-Install > > > > I extracted the 127 top-level distros, then excluded all distros > > beginning with Acme, Bundle or Task. That left 114 distros, which I > > attempted to install against Perl 5 blead (commit 930ded654, Apr 2 > > 2019) on FreeBSD-11.2 (threaded) using cpanm as the installer. (I.e., > > the same approach I take toward monthly testing of the "CPAN-River- > > 3000".) > > > > Certain modules failed to install for reasons that were expected given > > that they, or their prerequisites, do not get a PASS grade during the > > monthly CPAN-River-3000 process. Other modules failed to install > > because of upstream breakage in blead. However, I couldn't identify > > any distributions which failed due to Module::Install itself. > > > > Thank you very much.
> > CPANtesters currently all green for this distro. > > http://matrix.cpantesters.org/?dist=Module-Install;perl=5.29.10;reports=1 > > Can this ticket be marked Resolved?
Not really. The change in blead, v5.27.6-180-g0301e89953, that broke M::I ras reverted by v5.28.0-RC1-15-g9f9606382c, due to the M::I breakage. But in theory we would like to reapply athe change at some point in the future when a fixed M::I has been included in all the distributions which include it and are affected by it. I'm going to move this from 5.30.0 blocker to 5.32.0 blocker -- Nothing ventured, nothing lost.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 847b
On Tue, 23 Apr 2019 08:03:46 -0700, davem wrote: Show quoted text
> > CPANtesters currently all green for this distro. > > > > http://matrix.cpantesters.org/?dist=Module-Install;perl=5.29.10;reports=1 > > > > Can this ticket be marked Resolved?
> > Not really. The change in blead, v5.27.6-180-g0301e89953, that broke M::I > ras reverted by v5.28.0-RC1-15-g9f9606382c, due to the M::I breakage. But > in theory we would like to reapply athe change at some point in the future > when a fixed M::I has been included in all the distributions which include > it and are affected by it. > > I'm going to move this from 5.30.0 blocker to 5.32.0 blocker
Since nothing on cpan seems to be affected anymore, this should be safe to resolve in 5.31 (by reapplying the reverted portion of the commit). If we are still unsure we could smoke the change against cpan first.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Fri, 26 Apr 2019 04:05:42 GMT, ether wrote: Show quoted text
> On Tue, 23 Apr 2019 08:03:46 -0700, davem wrote: >
> > > CPANtesters currently all green for this distro. > > > > > > http://matrix.cpantesters.org/?dist=Module- > > > Install;perl=5.29.10;reports=1 > > > > > > Can this ticket be marked Resolved?
> > > > Not really. The change in blead, v5.27.6-180-g0301e89953, that broke > > M::I > > ras reverted by v5.28.0-RC1-15-g9f9606382c, due to the M::I breakage. > > But > > in theory we would like to reapply athe change at some point in the > > future > > when a fixed M::I has been included in all the distributions which > > include > > it and are affected by it. > > > > I'm going to move this from 5.30.0 blocker to 5.32.0 blocker
> > Since nothing on cpan seems to be affected anymore, this should be > safe to resolve > in 5.31 (by reapplying the reverted portion of the commit). If we are > still unsure > we could smoke the change against cpan first.
I have created the following branch: smoke-me/jkeenan/rt-132577-module-install ... in which the reverted portion of the original commit is re-applied. This can facilitate CPAN smoking (which we will have to arrange). Thank you very much. -- 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