perl5.18.0-broken -- breaks most existing programs w/warnings

p5pRT commented 11 years ago

Migrated from rt.perl.org#119493 (status was 'rejected')

Searchable as RT119493$

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

I was trying to install perl 5.18.0 (I found a version for suse --- but it breaks nearly all existing scripts).

First big problem -- it generates warnings by default on what was previously legal code. (my $_\, given\, when\, etc).

It's considered normal to treat warnings as errors and my code does just that... it rolls over and dies.

Telling someone that these things were deprecated might be one thing. But causing any program that uses these legal constructs to now fail w/o anything in the release notes about them being deprecated -- I can't see how this is at all responsible.

--- Then I try to update my cpan modules\, but seems CPAN got broken as well...

cpan Cannot do `initialize' in Term::ReadLine::Gnu at /usr/lib/perl5/5.18.0/CPAN.pm line 273.

---- I tried chaing the PERL_RL options\, but that doesn't seem to work so well:

export PERL_RL="o=0" Ishtar:law/bin> cpan Terminal does not support AddHistory. cpan[1]> install Term::Readline::Gnu CPAN::SQLite not installed\, trying to work without Reading '/home/CPAN-ishtar-build-cache/Metadata' Database was generated on Sun\, 25 Aug 2013 22:07:29 GMT Warning: Cannot install Term::Readline::Gnu\, don't know what it is. Try the command

i /Term::Readline::Gnu/

to find objects with matching identifiers.

.................... 20 subroutines in Term::ReadLine redefined Terminal does not support GetHistory. Lockfile removed. Cannot do `initialize' in Term::ReadLine::Gnu at /usr/lib/perl5/5.18.0/CPAN.pm line 273.

----

The first error is bad enough -- there needs to be a way of setting something in the environment.

I tried adding -M-warnings=experimental to my PERL5OPTS but that doesn't seem to work for any complicated program that uses modules that have "use warnings" (or maybe lexical use warnings) something turns the experimental warnings back on.

This is now the output of a typical perl prog on my system:

snapper.pl
Use of my $_ is experimental at /home/law/bin/lib/Types.pm line 172. Use of my $_ is experimental at /home/law/bin/lib/Dbg.pm line 214. Use of my $_ is experimental at /home/law/bin/lib/Data/Vars.pm line 162. given is experimental at /home/law/bin/lib/Cmds.pm line 96. when is experimental at /home/law/bin/lib/Cmds.pm line 97. Use of my $_ is experimental at /home/law/bin/lib/Cmds.pm line 98. when is experimental at /home/law/bin/lib/Cmds.pm line 100. when is experimental at /home/law/bin/lib/Cmds.pm line 133. given is experimental at /home/law/bin/lib/Cmds.pm line 136. when is experimental at /home/law/bin/lib/Cmds.pm line 137. when is experimental at /home/law/bin/lib/Cmds.pm line 141. when is experimental at /home/law/bin/lib/Cmds.pm line 142. Use of my $_ is experimental at /home/law/bin/lib/Lvm_Utils.pm line 357. require Lvm_Utils.pm called at /home/law/bin/snapper.pl line 27 main::BEGIN() called at /home/law/bin/lib/Lvm_Utils.pm line 357 eval {...} called at /home/law/bin/lib/Lvm_Utils.pm line 357 given is experimental at /home/law/bin/lib/Lvm_Utils.pm line 434. require Lvm_Utils.pm called at /home/law/bin/snapper.pl line 27 main::BEGIN() called at /home/law/bin/lib/Lvm_Utils.pm line 434 eval {...} called at /home/law/bin/lib/Lvm_Utils.pm line 434 when is experimental at /home/law/bin/lib/Lvm_Utils.pm line 435. require Lvm_Utils.pm called at /home/law/bin/snapper.pl line 27 main::BEGIN() called at /home/law/bin/lib/Lvm_Utils.pm line 435 eval {...} called at /home/law/bin/lib/Lvm_Utils.pm line 435 when is experimental at /home/law/bin/lib/Lvm_Utils.pm line 440. require Lvm_Utils.pm called at /home/law/bin/snapper.pl line 27 main::BEGIN() called at /home/law/bin/lib/Lvm_Utils.pm line 440 eval {...} called at /home/law/bin/lib/Lvm_Utils.pm line 440 Use of my $_ is experimental at /home/law/bin/lib/Cmd.pm line 26. at /home/law/bin/lib/Cmd.pm line 26. require Cmd.pm called at /home/law/bin/lib/Priv.pm line 7 Priv::BEGIN() called at /home/law/bin/lib/Cmd.pm line 26 eval {...} called at /home/law/bin/lib/Cmd.pm line 26 require Priv.pm called at /home/law/bin/snapper.pl line 189 Lv::Snapshot_Ops::BEGIN() called at /home/law/bin/lib/Cmd.pm line 26 eval {...} called at /home/law/bin/lib/Cmd.pm line 26 at /home/law/bin/lib/Cmd.pm line 26. require Cmd.pm called at /home/law/bin/lib/Priv.pm line 7 Priv::BEGIN() called at /home/law/bin/lib/Cmd.pm line 26 eval {...} called at /home/law/bin/lib/Cmd.pm line 26 require Priv.pm called at /home/law/bin/snapper.pl line 189 Lv::Snapshot_Ops::BEGIN() called at /home/law/bin/lib/Cmd.pm line 26 eval {...} called at /home/law/bin/lib/Cmd.pm line 26 Compilation failed in require at /home/law/bin/lib/Priv.pm line 7. at /home/law/bin/lib/Priv.pm line 7. Priv::BEGIN() called at /home/law/bin/lib/Priv.pm line 7 eval {...} called at /home/law/bin/lib/Priv.pm line 7 require Priv.pm called at /home/law/bin/snapper.pl line 189 Lv::Snapshot_Ops::BEGIN() called at /home/law/bin/lib/Priv.pm line 7 eval {...} called at /home/law/bin/lib/Priv.pm line 7 BEGIN failed--compilation aborted at /home/law/bin/lib/Priv.pm line 7. at /home/law/bin/lib/Priv.pm line 7. require Priv.pm called at /home/law/bin/snapper.pl line 189 Lv::Snapshot_Ops::BEGIN() called at /home/law/bin/lib/Priv.pm line 7 eval {...} called at /home/law/bin/lib/Priv.pm line 7 Compilation failed in require at /home/law/bin/snapper.pl line 189. at /home/law/bin/snapper.pl line 189. Lv::Snapshot_Ops::BEGIN() called at /home/law/bin/snapper.pl line 189 eval {...} called at /home/law/bin/snapper.pl line 189 BEGIN failed--compilation aborted at /home/law/bin/snapper.pl line 189. at /home/law/bin/snapper.pl line 189.

---- With everything failing all over the place.

Um... did anyone bother to test 5.18 with cpan before it went out the door .. or anything code that "use's warnings";

I was tried recompiling the mods in cpan\, as that was callable w/o using Term\, but no go...

So how was it expected that this would be useful for anyone? I.e. shipping a perl that disables most programs on arrival?

Maybe a 5.18.1 is due out immediately?

I'm not sure how to upgrade to this perl without causing lots of pain...

For me\, I guess I'm going to restore my system from backups to undo the perl-upgrade damage I inflicted on it.

Perl Info

``` Flags: category=core severity=critical This perlbug was built using Perl 5.18.0 - Fri Aug 23 22:48:54 UTC 2013 It is being executed now by Perl 5.18.0 - Fri Aug 23 22:46:08 UTC 2013. Site configuration information for perl 5.18.0: Configured by abuild at Fri Aug 23 22:46:08 UTC 2013. Summary of my perl5 (revision 5 version 18 subversion 0) configuration: Platform: osname=linux, osvers=3.7.10-1.1-default, archname=x86_64-linux-thread-multi uname='linux cloud106 3.7.10-1.1-default #1 smp thu feb 28 15:06:29 utc 2013 (82d3f21) x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl -Dinc_version_list=none' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.8.1 20130806 [gcc-4_8-branch revision 201525]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.18.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.18' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.18.0/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector' Locally applied patches: @INC for perl 5.18.0: /home/law/bin/lib /usr/lib/perl5/site_perl/5.18.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.18.0 /usr/lib/perl5/vendor_perl/5.18.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.18.0 /usr/lib/perl5/5.18.0/x86_64-linux-thread-multi /usr/lib/perl5/5.18.0 /usr/lib/perl5/site_perl/5.18.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.18.0 /usr/lib/perl5/site_perl . Environment for perl 5.18.0: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib64/mpi/gcc/openmpi/lib64 LOGDIR (unset) PATH=/home/law/bin/lib:/sbin:/usr/local/sbin:/usr/lib64/mpi/gcc/openmpi/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:.:/usr/lib/qt3/bin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib PERL5OPT=-Mutf8 -CSA -I/home/law/bin/lib -M-warnings=experimental PERL_BADLANG (unset) SHELL=/bin/bash ```

p5pRT commented 11 years ago

From @rjbs

* Linda Walsh \perlbug\-followup@perl\.org [2013-08-27T20:26:41]

I was trying to install perl 5.18.0 (I found a version for suse --- but it breaks nearly all existing scripts).

First big problem -- it generates warnings by default on what was previously legal code. (my $_\, given\, when\, etc).

It's considered normal to treat warnings as errors and my code does just that... it rolls over and dies.

First off\, I'd like to take issue with the statement made several times in your report that 5.18.0 "breaks most programs with warnings."

Evidence suggests that relatively little code "with warnings" was "broken\," because as near as we could tell\, fatal warnings are fairly rare. Of course\, we can only test:

* published code on the CPAN * private code that is tested against blead and reported on by concerned programmers

Nonetheless\, I think it was the general feeling among "the list" that the breakage was pretty minor. Warnings for "my $_" were added in Dec 2012 and warnings for ~~ were added (admittedly lamentably late) in Apr 2013.

Although there have been plenty of complaints that these warnings are "annoying\," yours is the first complaint that anything has been broken.

Nonetheless\, the real issue seems to be:

Telling someone that these things were deprecated might be one thing. But causing any program that uses these legal constructs to now fail w/o anything in the release notes about them being deprecated -- I can't see how this is at all responsible.

First\, these things have not been marked deprecated\, but experimental. Whatever\, though: it's not the point\, is it? The point is that instead of "telling someone\," we've added warnings.

The thing is\, warnings are how we communciate these things. In general\, experience shows that users generally *do not* read the release notes. That's understandable. Even with all the time spent trying to make the release notes put the most important stuff up front and in concise wording\, the notes don't seem to get read.

(The addition of these "experimental" warnings and the means to disable them is the first item listed in perl5180delta.)

Um... did anyone bother to test 5.18 with cpan before it went out the door .. or anything code that "use's warnings"; [...] So how was it expected that this would be useful for anyone? I.e. shipping a perl that disables most programs on arrival?

Yup! I run all my code\, CPAN code and all\, every day\, with the latest release of the devel cycle. Right now\, I'm running 5.19.3. It has been great for shaking out bugs. I also test my work code against blead\, which helps find that such-and-such bugfix will negatively impact work. Then I can prepare for the coming breakage months in advance.

The perspective I suggest you consider is that of a world in which we did *not* issue such warnings.

The warnings are easy to work around. You either say\, "Gosh\, this feature is experimental? I didn't know. I better stop relying on it in critical systems\, since it is subject to massive change in the next version" or you say\, "I don't have time to reëngineer\, I will disable this warning" as shown in the perldelta. I suggested the former\, for critical code\, but the latter is quite easy\, and I used it to fix some of the very few parts of the CPAN broken by the introduction of these warnings.

If you replace the affected code to eliminate experimental warnings\, then when the behavior of ~~ or lexical topic changes radically in the next major version of Perl 5\, *you will be safe*. Alternately\, you can know just which hunks of code to review based on (a) the emission of warnings or (b) grepping for "no warnings .experimental".

If no warnings were issued\, and you missed the entry in perldelta somewhere that such-and-such feature was experimental\, then when 5.x came\, changing things\, your code would *actually* break. That is: its runtime behavior would change! Much worse than having a compile-time error telling you "you're using something subject to change without acknowledging it\," you'd just get a program that did something else! Yikes!

In the past\, there has been an unpleasant feeling of pressure to keep bad behavior that "was never guaranteed" but only offered experimentally\, as clearly noted in "perl598delta" 87% down the file. We want to make it very clear that using experimental features is an opt-in\, and it was something that was carefully considered. In the future\, expect *more* such warnings\, not *less*. Of course\, they'll be for new features\, so your old code won't be affected. This transition period is a bit unpleasant\, but it's necessary to establish the new procedure.

See also all the work done to figure out the status of experiments\, via the commits to pod/perlexperiment.pod since 5.16.0 and the tickets related to it. I think it's been worth doing\, and that it will definitely pay dividends in the maintainability of both perl and Perl programs in the future.

I'm not sure what\, if any\, further response to this ticket is required. Please let me know or I will close this ticket in a few days.

Then I try to update my cpan modules\, but seems CPAN got broken as well...

This seeems unrelated. I will be interested to hear back what the solution to this problem is. I'm guessing you need to tweak your CPAN config or environment to drop mention of ReadLine::Gnu\, but that's a complete guess.

-- rjbs

p5pRT commented 11 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 11 years ago

From doherty@cs.dal.ca

On 13-08-27 09:26 PM\, Linda Walsh (via RT) wrote:

export PERL_RL="o=0" Ishtar:law/bin> cpan Terminal does not support AddHistory. cpan[1]> install Term::Readline::Gnu CPAN::SQLite not installed\, trying to work without Reading '/home/CPAN-ishtar-build-cache/Metadata' Database was generated on Sun\, 25 Aug 2013 22:07:29 GMT Warning: Cannot install Term::Readline::Gnu\, don't know what it is. Try the command
i /Term&#8203;::Readline&#8203;::Gnu/
to find objects with matching identifiers.

The module is called Term::ReadLine::Gnu\, not Term::Readline::Gnu.

That may not fix all your problems\, though.

-Mike

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Tue Aug 27 18:37:46 2013\, perl.p5p@rjbs.manxome.org wrote:

First big problem -- it generates warnings by default on what was previously legal code. (my $_\, given\, when\, etc).

It's considered normal to treat warnings as errors and my code does just that... it rolls over and dies.

First off\, I'd like to take issue with the statement made several times in your report that 5.18.0 "breaks most programs with warnings."

Evidence suggests that relatively little code "with warnings" was "broken\," because as near as we could tell\, fatal warnings are fairly rare. Of course\,

In nearly any treatise on good perl programming\, it is said to use warnings and strict and to address all messages that come out of that. It is recommended in many places to treat warnings as errors. Given that such is common advice\, and would I dare to say common sense\, how could one release something that would flag a warning in a large (maybe not the majority) number of programs.

we can only test:

* published code on the CPAN

This is not representative of the code body\, at large. Going through the listed recommendations of getting code on CPAN would turn up that use of any of the constructs you flag warnings for "should" be minimal to non-existent. I specifically remember that I rewrote code for CPAN to NOT use 'given/while'\, as they were features that were not compatible with 5.6 and to try to minimize the use of such in order to maximize the utility of the code on CPAN.

You can't use CPAN as a "indicator" of what code is like outside of CPAN as the same constraints don't apply.

You can only use a sampling of a smaller population to determine a larger\, overall population's behavior in something IF and only IF\, the smaller population is selected at random out of the larger population (AI/statistical reasoning). The CPAN population is far from being close to a true random sampling given the recommendations one is given as one goes to submit a module for CPAN inclusion.

* private code that is tested against blead and reported on by concerned programmers

A statistically irrelevant sample\, more likely to be composed of those who are p5p-porters ("perl-insiders") than not.

Nonetheless\, I think it was the general feeling among "the list" that the breakage was pretty minor. Warnings for "my $_" were added in Dec 2012 and warnings for ~~ were added (admittedly lamentably late) in Apr 2013.

The opinion of what public list? The opinions of private lists do not apply to the general perl-use public if the list isn't open to such. It is not\, and cannot be used to justify actions that are to be carried out and dumped on the perl-programming public.

You (and this is specifically aimed at you Ricardo)\, by your previous actions and how you choose to exclude people (no matter "how right"\, you or those supporting your actions\, feel they were/are justified)\, have created a *self-approving* environment of yes-men. Those who might have objected have already been labeled as "unambiguously [sic] unacceptable communicators" and excised from the list. If you exclude the 'outliers' from consideration in your decisions\, you are automatically\, NOT going to get a relevant sampling that represents the larger perl-using public's usage.

Although there have been plenty of complaints that these warnings are "annoying\," yours is the first complaint that anything has been broken.

It is said among more conservative developers\, that anyone who ignores warnings in their program is a fool. I take that seriously and work to have any program fail on warnings due to the emphasis that historically they represent a much higher statistical chance that something is wrong than in programs that have no warnings.

Nonetheless\, the real issue seems to be:

Telling someone that these things were deprecated might be one thing. But causing any program that uses these legal constructs to now fail w/o anything in the release notes about them being deprecated -- I can't see how this is at all responsible.

First\, these things have not been marked deprecated\, but experimental. Whatever\, though: it's not the point\, is it? The point is that instead of "telling someone\," we've added warnings.

Instead of giving the advance warning that deprecation would have required\, by going the warning route you've violated the _principle_\, if not the letter\, of releasing things that cause breakage on a wide scale without an advance notification cycle.

The thing is\, warnings are how we communciate these things. In general\, experience shows that users generally *do not* read the release notes. That's understandable. Even with all the time spent trying to make the release notes put the most important stuff up front and in concise wording\, the notes don't seem to get read.

That doesn't mean you stop releasing them. I do read the delta's\, though usually after installing the new version -- as I don't expect things to already be broken\, and really have no easy way to determine what in the delta is relevant to my code.

(The addition of these "experimental" warnings and the means to disable them is the first item listed in perl5180delta.)

That is a point at issue.

There are no instructions on how to disable them on a site-wide basis. The only method given is one that works by modifying the source code of each module -- a laborious and usually unacceptable change to be done done on the spur of a moment\, but one that needs some planning to exhaustively change all source modules to comply with.

I would have issue with the idea of flagging warnings for anything that people might commonly be using -- like given/when (which was perl's answer for the lack of a case statement) and was useful outside of the affects of "~~" which I\, only occasionally\, find of use.

I see no benefit in releasing code that uses experimental constructs nor putting such constructs to use in vital roles and would "doubly"\, doubt you'd see something on CPAN using such due to compatibility concerns. As this comes off to me\, any feature released after 5.6 is experimental.

Um... did anyone bother to test 5.18 with cpan before it went out the door .. or anything code that "use's warnings"; [...] So how was it expected that this would be useful for anyone? I.e. shipping a perl that disables most programs on arrival?

Yup! I run all my code\, CPAN code and all\, every day\, with the latest release of the devel cycle. Right now\, I'm running 5.19.3. It has been great for shaking out bugs. I also test my work code against blead\, which helps find that such-and-such bugfix will negatively impact work. Then I can prepare for the coming breakage months in advance.

If perl was portable enough to be generated in diverse environments\, more might take advantage of that. But portability issues exist and have created distro's who will not support anything other than a sterile build of perl under their own build system which makes it hard for end-perl users to do the same.

The perspective I suggest you consider is that of a world in which we did *not* issue such warnings.

But give a cycle advanced notice?

The warnings are easy to work around. You either say\, "Gosh\, this feature is experimental? I didn't know. I better stop relying on it in critical systems\, since it is subject to massive change in the next version" or you say\, "I don't have time to re�ngineer\, I will disable this warning" as shown in the perldelta. I suggested the former\, for critical code\, but the latter is quite easy\, and I used it to fix some of the very few parts of the CPAN broken by the introduction of these warnings.

If it was doable on a site-wide basis for those who have multiple perl modules that would need to have it disabled in each module\, that would have been acceptable but it doesn't appear that it is.

If you replace the affected code to eliminate experimental warnings\, then when the behavior of ~~ or lexical topic changes radically in the next major version of Perl 5\, *you will be safe*. Alternately\, you can know just which hunks of code to review based on (a) the emission of warnings or (b) grepping for "no warnings .experimental".

It depends on how the feature is being used and how long it has been in production perls without being tagged experimental.

I don't recall when/given being tagged as experimental in 5.10 or 5.12 or 5.14...etc... When something experiemental continues into the next version where it is no longer listed as experimental\, its not.

If no warnings were issued\, and you missed the entry in perldelta somewhere that such-and-such feature was experimental\, then when 5.x came\, changing things\, your code would *actually* break. That is: its runtime behavior would change! Much worse than having a compile-time error telling you "you're using something subject to change without acknowledging it\," you'd just get a program that did something else! Yikes!

Not if there was a cycle advance notice.

In the past\, there has been an unpleasant feeling of pressure to keep bad behavior that "was never guaranteed" but only offered experimentally\, as clearly noted in "perl598delta" 87% down the file.

Bzzzt. 5.9.8 isn't a public stable release. If it was not documented as experiemental in 5.10.0 and 5.12.0...etc\, then it the assumption is that by the time it had reached the public release where it is no longer called experimental\, it isnt'.

See also all the work done to figure out the status of experiments\, via the commits to pod/perlexperiment.pod since 5.16.0 and the tickets related to it. I think it's been worth doing\, and that it will definitely pay dividends in the maintainability of both perl and Perl programs in the future.

Here's where you broke it. If someone puts "use 5.18.x" in their code\, then they get the new warnings. Otherwise\, you use the new feature "expermental::warnings"; By turning on this new feature by default\, code that treats warnings as failures (as they've been told to not ignore warnings) will fail.

I'm not sure what\, if any\, further response to this ticket is required. Please let me know or I will close this ticket in a few days.

Then I try to update my cpan modules\, but seems CPAN got broken as well...

This seeems unrelated. I will be interested to hear back what the solution to this problem is. I'm guessing you need to tweak your CPAN config or environment to drop mention of ReadLine::Gnu\, but that's a complete guess.

I didn't know it had even been deprecated\, let alone killed.

p5pRT commented 11 years ago

From @Leont

On Wed\, Aug 28\, 2013 at 11:31 PM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:

 You can't use CPAN as a "indicator" of what code is like outside of
CPAN as the same constraints don't apply.

It's not perfect but it's the best thing we've got. If you've got any better ideas you're welcome to suggest them\, stop pissing otherwise.

 The opinion of what public list?  The opinions of private lists do
not apply to the general perl-use public if the list isn't open to such. It is not\, and cannot be used to justify actions that are to be carried out and dumped on the perl-programming public.

Perl5-porters\, there isn't any other place where we make such decisions.

     You $and this is specifically aimed at you Ricardo$\, by your
previous actions and how you choose to exclude people (no matter "how right"\, you or those supporting your actions\, feel they were/are justified)\, have created a *self-approving* environment of yes-men. Those who might have objected have already been labeled as "unambiguously [sic] unacceptable communicators" and excised from the list. If you exclude the 'outliers' from consideration in your decisions\, you are automatically\, NOT going to get a relevant sampling that represents the larger perl-using public's usage.

These accusations are tiresome and don't make your point any more convincing. You are not persecuted for your opinions; making this personal is only increasing the odds of you being banned from the bugtracker too. Stop being toxic\, start taking responsibility for your own actions.

Leon

p5pRT commented 11 years ago

From @xdg

Linda\, your bug report seems to be:

(1) I disagree with the decision to have experimental warnings on by default

(2) I mistyped the name of a module I wanted to install

Neither of these are bugs.

#1 is a difference of opinion. The new warning was debated in the only forum which matters (p5p) and decided by the only person that matters (the current Pumpking). That's how Perl development works. No decision ever satisfies everyone. You're welcome to disagree\, but it's not going to change merely because you disagree.

#2 is your own error

This ticket should be closed.

-- David Golden \xdg@xdg\.me Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg

p5pRT commented 11 years ago

From @jkeenan

On Wed Aug 28 16:31:21 2013\, xdg@xdg.me wrote:

Linda\, your bug report seems to be:

(1) I disagree with the decision to have experimental warnings on by default

(2) I mistyped the name of a module I wanted to install

Neither of these are bugs.

#1 is a difference of opinion. The new warning was debated in the only forum which matters (p5p) and decided by the only person that matters (the current Pumpking). That's how Perl development works. No decision ever satisfies everyone. You're welcome to disagree\, but it's not going to change merely because you disagree.

#2 is your own error

This ticket should be closed.

I support this recommendation and have closed this ticket.

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

@jkeenan - Status changed from 'open' to 'rejected'

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Wed Aug 28 15:47:43 2013\, LeonT wrote:

On Wed\, Aug 28\, 2013 at 11:31 PM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:
 You can't use CPAN as a "indicator" of what code is like outside of
CPAN as the same constraints don't apply.
It's not perfect but it's the best thing we've got. If you've got any better ideas you're welcome to suggest them\, stop pissing otherwise.

It's a poor indicator. To use it and not know it is a poor indicator is pissing on users. Part of the problem is creating an environment of those who agree with those already in power who exclude those who don't.

 The opinion of what public list?  The opinions of private lists do
not apply to the general perl-use public if the list isn't open to such. It is not\, and cannot be used to justify actions that are to be carried out and dumped on the perl-programming public.
Perl5-porters\, there isn't any other place where we make such decisions.

It's like Bush surrounding himself with Cheney and friends and there being any wonder that he's was widely rated as the worst president in history. If you surround yourself who only say thing you want to hear that are said in pleasant fluffy\, bland ways\, you are unlikely to get any representative sample of anyone who might disagree with you lest the be ostracized and attacked as not a member of the group.

     You $and this is specifically aimed at you Ricardo$\, by your
previous actions and how you choose to exclude people (no matter "how right"\, you or those supporting your actions\, feel they were/are justified)\, have created a *self-approving* environment of yes-men. Those who might have objected have already been labeled as "unambiguously [sic] unacceptable communicators" and excised from the list. If you exclude the 'outliers' from consideration in your decisions\, you are automatically\, NOT going to get a relevant sampling that represents the larger perl-using public's usage.
These accusations are tiresome

It's tiresome to have someone state truisms that exactly describe their perception of the situation. That another group of insiders wouldn't have that same impression is unremarkable.

and don't make your point any more convincing. You are not persecuted for your opinions.

I am banned from the list because of the opinion I have that how I express my opinions isn't inappropriate for the environment that was presented nor the the trite treatment of issues brought forth.

making this personal is only increasing the odds of you being banned from the bugtracker too.

I'm not making it personal any more than it was before when 1 person who decided to take action they thought was best for the group of people who's opinions "mattered" \, to protect them and added a personal block (blocking a single person which is ***inherently*** personal).

Stop being toxic.

Stop using vague nebulous mean nothing words. What\, are you calling toxic that would fit a normal definition of something that is biologically injurious to health? If you go and sit on a cactus\, it will injure you\, but that doesn't mean it is toxic.

start taking responsibility for your own actions - Leon

I have been for some time and continue to do so\, in spite of considerable pressure to conform to group norms above all else.

If I have opinions on something\, keeping them to myself is not responsible.

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Wed Aug 28 16:41:16 2013\, jkeenan wrote:

On Wed Aug 28 16:31:21 2013\, xdg@xdg.me wrote:

Linda\, your bug report seems to be:

(1) I disagree with the decision to have experimental warnings on by default

(2) I mistyped the name of a module I wanted to install

Neither of these are bugs.

#1 is a difference of opinion. The new warning was debated in the only forum which matters (p5p)

A private forum where contrary opinions are vehemently silenced to the point of causing anyone who expresses them and defends them to be excised from the list.

and decided by the only person that matters (the current Pumpking).

Oh\, is that the person I'm suppose to respect for volunteering for such an authoritarian position? That they exclude outside opinions and close off their personal forums of input is not a cause for respect.

That's how Perl development works.

No decision ever satisfies everyone. You're welcome to disagree\, but it's not going to change merely because you disagree.

I will not agree because someone has the power to make bad decisions the power of the land.

#2 is your own error

I don't see how it would work under 5.16.2 and not under 5.18.0. I didn't change spellings or configs for 5.18.0. There is no reference to Readline in my config: $CPAN::Config = { 'applypatch' => q[]\, 'auto_commit' => q[1]\, 'build_cache' => q[64]\, 'build_dir' => q[/home/CPAN-ishtar-build-cache]\, 'build_dir_reuse' => q[0]\, 'build_requires_install_policy' => q[yes]\, 'bzip2' => q[/usr/bin/bzip2]\, 'cache_metadata' => q[1]\, 'check_sigs' => q[0]\, 'colorize_debug' => q[1]\, 'colorize_output' => q[0]\, 'colorize_print' => q[0]\, 'colorize_warn' => q[1]\, 'commandnumber_in_prompt' => q[1]\, 'connect_to_internet_ok' => q[1]\, 'cpan_home' => q[/home/CPAN-ishtar-build-cache]\, 'dontload_hash' => { }\, 'ftp' => q[]\, 'ftp_passive' => q[1]\, 'ftp_proxy' => q[http://web-proxy:8118]\, 'getcwd' => q[cwd]\, 'gpg' => q[/usr/bin/gpg]\, 'gzip' => q[/usr/bin/gzip]\, 'halt_on_failure' => q[0]\, 'histfile' => q[/home/CPAN-ishtar-build-cache/.histfile]\, 'histsize' => q[1000]\, 'http_proxy' => q[http://web-proxy:8118]\, 'inactivity_timeout' => q[15]\, 'index_expire' => q[5]\, 'inhibit_startup_message' => q[1]\, 'keep_source_where' => q[/Share/CPAN/sources]\, 'load_module_verbosity' => q[none]\, 'lynx' => q[/usr/bin/lynx]\, 'make' => q[/usr/bin/make]\, 'make_arg' => q[-j]\, 'make_install_arg' => q[UNINST=1]\, 'make_install_make_command' => q[sudo make]\, 'makepl_arg' => q[]\, 'mbuild_arg' => q[]\, 'mbuild_install_arg' => q[--uninst 1]\, 'mbuild_install_build_command' => q[sudo ./Build]\, 'mbuildpl_arg' => q[]\, 'ncftpget' => q[]\, 'no_proxy' => q[localhost\, 127.0.0.1]\, 'pager' => q[less]\, 'patch' => q[/usr/bin/patch]\, 'perl5lib_verbosity' => q[none]\, 'prefer_external_tar' => q[1]\, 'prefer_installer' => q[EUMM]\, 'prefs_dir' => q[/home/CPAN-ishtar-build-cache/prefs]\, 'prerequisites_policy' => q[follow]\, 'proxy_user' => q[]\, 'scan_cache' => q[atstart]\, 'shell' => q[/bin/bash]\, 'show_unparsable_versions' => q[0]\, 'show_upload_date' => q[1]\, 'show_zero_versions' => q[0]\, 'tar' => q[/bin/tar]\, 'tar_verbosity' => q[none]\, 'term_is_latin' => q[0]\, 'term_ornaments' => q[1]\, 'test_report' => q[1]\, 'trust_test_report_history' => q[0]\, 'unzip' => q[/usr/bin/unzip]\, 'urllist' => [q[http://mirrors.kernel.org/CPAN]\, q[/http://cpan.develooper.com/]\, q[http://httpupdate27.cpanel.net/CPAN]\, q[http://www.perl.com/CPAN/]\, q[http://www.cpan.org/]]\, 'use_sqlite' => q[1]\, 'username' => q[perl-diddler@tlinx.org]\, 'version_timeout' => q[5]\, 'wait_list' => q[]\, 'wget' => q[/usr/bin/wget]\, 'yaml_load_code' => q[1]\, 'yaml_module' => q[YAML::XS]\, }; 1; __END__

The code fails as downloaded from CPAN. IF the error is in there\, it is in the CORE code I downloaded.

To quote the previous poster: take responsibility for your own bugs.

This ticket should be closed. -- Irresponsibly attitude.

I support this recommendation and have closed this ticket.

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

From @xdg

On Wed\, Aug 28\, 2013 at 9:06 PM\, Linda Walsh via RT \perlbug\-followup@perl\.org wrote:

I will not agree because someone has the power to make bad decisions

the power of the land.

No one is asking you to agree. I am pointing out that opening a ticket about a difference of opinion that is already settled — whether you liked the decision process or not — is not going to change things.

Your opinion is not going to change the decision process and your opinion is not going to change the already decided outcome\, therefore your opinion is not a bug in Perl and the ticket tracker is the wrong forum in which to express it.

-- David Golden \xdg@xdg\.me Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg

p5pRT commented 11 years ago

From @rjbs

* Linda Walsh via RT \perlbug\-followup@perl\.org [2013-08-28T21:06:43]

#2 is your own error ---- I don't see how it would work under 5.16.2 and not under 5.18.0. I didn't change spellings or configs for 5.18.0. There is no reference to Readline in my config:

Jim misread\, I believe\, and thought that the problem was your mistyping of "install Term::Readline::Gnu" rather than ReadLine was at fault. I don't think that's the case.

The CPAN.pm issue seems to be distinct from the main thrust of this ticket\, which was about warnings. I suggest you take it up with https://rt.cpan.org/Dist/Display.html?Name=CPAN especially if you can provide any more information. I wonder if there's something in your environment?

At any rate\, I am not a CPAN.pm expert\, and CPAN.pm is mostly supported by the CPAN.pm bug queue\, rather than p5p. I have not heard any other reports of this problem and I can't reproduce it on the boxes I've upgraded to 5.18.x. From this position\, I can't offer any help\, even if this ticket *was* all about this CPAN.pm error.

-- rjbs

p5pRT commented 11 years ago

From victor@vsespb.ru

If you depend on something\, that is rarely used on CPAN\, but that is\, you belive\, typical use\, you can create a dummy module with a testsuite and submit to CPAN. This way it will break when someone tests CPAN to see if something breaks.

2013/8/29 Linda Walsh via RT \perlbug\-followup@perl\.org

 You can't use CPAN as a "indicator" of what code is like outside of
CPAN as the same constraints don't apply.

p5pRT commented 11 years ago

From @iabyn

On Wed\, Aug 28\, 2013 at 06:06:43PM -0700\, Linda Walsh via RT wrote:

#1 is a difference of opinion. The new warning was debated in the only forum which matters (p5p) --- A private forum where contrary opinions are vehemently silenced to the point of causing anyone who expresses them and defends them to be excised from the list.

Linda\, you have repeated this misapprehension several times. p5p is an open forum where matters of significant difference of opinion are often discussed. Banning individuals from the list is an *extremely* rare occurrence. In my 12+ years on the list I can only recall a single individual being banned\, that one being you. You may wish to reflect upon that fact for a bit.

-- You're only as old as you look.

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Thu Aug 29 03:30:40 2013\, davem wrote:

Linda\, you have repeated this misapprehension several times. p5p is an open forum where matters of significant difference of opinion are often discussed. Banning individuals from the list is an *extremely* rare occurrence. In my 12+ years on the list I can only recall a single individual being banned\, that one being you. You may wish to reflect upon that fact for a bit.

Yet the one individual you banned is also the one who would have flagged this as a serious problem before perl went out.

That one individual came up with 2 actions to mitigate the problem and no one here sees any issue with my suggest that they have bothered to mention. That makes me believe the group didn't come up with those options.

1) I asked why it was turned on by default for old programs. When a new feature is added\, isn't it that people must usually "opt-in"\, by\, at least\, saying "use \<5.latest>"? If it was new for 5.18\, then it should have only activated if I asked it to "use 5.18".

2) The compiler breaks existing programs and you don't care. How you can consider breakage on a wide scale not to be a problem is beyond me. It's almost malicious intent.

Yet did you give any way for someone to turn off that error in their environment or on their system? The solution is notably the worst kind in that it requires all programs be modified\, *immediately*\, before 5.18 is adopted -- and even then\, people may resist the upgrade due to fears about code they use or are missing in their review.

Since I've been using perl in 1990\, I've never encountered this level of source incompatibility out of any version. 5 Going from 4.x->5.0 was no where near as problematic as 5.16->18. This isn't about a design decision that *was* made -- its about it needing to be fixed in 5.18.1 so it won't be a barrier to installation when people can become aware of these issues by explicitly "use 5.18" or above. That can give those who want to test against new features in 5.18 a heads-up that the other things exist without affecting previously running programs (email routing and backups came to a halt as soon as I tried installing 5.18). Broken infrastructure is a consequence of perl breaking key scripts. Without a site and/or computer wide way of disabling the new perl SPAMS the user with massive repetition of the same errors in out of every module.

It doesn't seem to be the case that you can turn the warnings on a per-file basis. Having 10-15 structures in one program file\, They are just structures... I have to put in changes in each "package" to turn off those errors. How could this be considered anything but extremely intrusive.

Yet p5p seems to revel in the breakage they cause\, because their cause is just (or so they all agree).

This is still a bug despite your rejecting the messenger (again).

p5pRT commented 11 years ago

From @tux

On Thu\, 29 Aug 2013 14:42:12 -0700\, "Linda Walsh via RT" \perlbug\-followup@perl\.org wrote:

Linda\, you have repeated this misapprehension several times. p5p is an open forum where matters of significant difference of opinion are often discussed. Banning individuals from the list is an *extremely* rare occurrence. In my 12+ years on the list I can only recall a single individual being banned\, that one being you. You may wish to reflect
upon that fact for a bit. ---- Yet the one individual you banned is also the one who would have flagged this as a serious problem before perl went out.

So well hidden in rants that go on and on that most people that care do not even read the real problem hidden in the rants.

If you could just step over the fact that your opinions sometimes differ and report problems concise and to the point in a way that the people that can solve the problems are able to immediately take action when they can reproduce the problem at hand\, you would be so much more appreciated.

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

Perl / perl5