Skip Menu |
Report information
Id: 122670
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: slaven [at] rezic.de
Cc:
AdminCc:

Operating System: freebsd
PatchStatus: (no value)
Severity: medium
Type: library
Perl Version: 5.20.1
Fixed In: (no value)



From: slaven [...] rezic.de
To: perlbug [...] perl.org
Date: Sun, 31 Aug 2014 20:41:44 +0200 (CEST)
CC: srezic [...] cpan.org
Subject: Module::CoreList version problems
Download (untitled) / with headers
text/plain 3.4k
This is a bug report for perl from slaven@rezic.de, generated with the help of perlbug 1.40 running under perl 5.20.1. ----------------------------------------------------------------- [Please describe your issue here] 5.20.1-RC1 ships with Module::CoreList 5.020001, while the newest on CPAN is 5.021003. Unfortunately 5.21.3 came before 5.20.1, so the latest version on CPAN is missing the 5.20.1 information. This is already causing breakage, e.g. distributions using Test::Prereq have test failures. I have the feeling that the current versioning scheme (Module::CoreList version == perl version) is problematic. Just using an increasing number or a date-based version number would be better. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=library severity=medium module=Module::CoreList --- Site configuration information for perl 5.20.1: Configured by eserte at Mon Aug 25 21:48:43 CEST 2014. Summary of my perl5 (revision 5 version 20 subversion 1) configuration: Platform: osname=freebsd, osvers=9.2-release, archname=amd64-freebsd uname='freebsd cvrsnica.herceg.de 9.2-release freebsd 9.2-release #0 r255898: thu sep 26 22:50:31 utc 2013 root@bake.isc.freebsd.org:usrobjusrsrcsysgeneric amd64 ' config_args='-D useshrplib=true -Dprefix=/usr/perl5.20.1-RC1 -Dusemymalloc=n -D cc=ccache cc -Dgccansipedantic -de' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='ccache cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', optimize='-O2 -pipe', cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 20070831 patched [FreeBSD]', 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='ccache cc', ldflags ='-Wl,-E -fstack-protector -L/usr/local/lib' libpth=/usr/lib /usr/local/lib /usr/include/gcc/4.2 /usr/lib libs=-lgdbm -lm -lcrypt -lutil -lc perllibs=-lm -lcrypt -lutil -lc libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/perl5.20.1-RC1/lib/5.20.1/amd64-freebsd/CORE' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector' Locally applied patches: RC1 --- @INC for perl 5.20.1: /usr/perl5.20.1-RC1/lib/site_perl/5.20.1/amd64-freebsd /usr/perl5.20.1-RC1/lib/site_perl/5.20.1 /usr/perl5.20.1-RC1/lib/5.20.1/amd64-freebsd /usr/perl5.20.1-RC1/lib/5.20.1 . --- Environment for perl 5.20.1: HOME=/home/e/eserte LANG (unset) LANGUAGE (unset) LC_ALL=de_DE.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/e/eserte/bin/freebsd9.1:/home/e/eserte/bin/sh:/home/e/eserte/bin:/usr/games:/home/e/eserte/devel PERLDOC=-MPod::Perldoc::ToTextOverstrike PERL_BADLANG (unset) PERL_HTML_DISPLAY_CLASS=HTML::Display::Mozilla SHELL=/usr/local/bin/zsh
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
Dana Ned 31. Kol 2014, 11:43:40, slaven@rezic.de reče: Show quoted text
> > 5.20.1-RC1 ships with Module::CoreList 5.020001, while the newest on > CPAN is 5.021003. Unfortunately 5.21.3 came before 5.20.1, so the > latest version on CPAN is missing the 5.20.1 information. This is > already causing breakage, e.g. distributions using Test::Prereq have > test failures. > > I have the feeling that the current versioning scheme > (Module::CoreList version == perl version) is problematic. Just using > an increasing number or a date-based version number would be better. >
Maybe I should outline the possible problems here: a user who installs perl 5.20.1 and then upgrades his modules (e.g. by using CPAN.pm's "upgrade" command) would get an *unusable* Module::CoreList. This will break all modules depending on correct Module::CoreList information, for example Test::Prereq (https://rt.cpan.org/Public/Bug/Display.html?id=98445 ), modules depending on Test::Prereq (e.g. CPAN::Mini::Tested, Netscape::Bookmarks, Distribution::Cooker...), or Pinto (https://github.com/thaljef/Pinto/issues/167 ). IMHO this should be fixed before the perl 5.20.1 release, either within perl 5.20.1, or using a CPAN release of Module::CoreList.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Mon Sep 08 11:26:16 2014, slaven@rezic.de wrote: Show quoted text
> Dana Ned 31. Kol 2014, 11:43:40, slaven@rezic.de reče: >
> > > > 5.20.1-RC1 ships with Module::CoreList 5.020001, while the newest on > > CPAN is 5.021003. Unfortunately 5.21.3 came before 5.20.1, so the > > latest version on CPAN is missing the 5.20.1 information. This is > > already causing breakage, e.g. distributions using Test::Prereq have > > test failures. > > > > I have the feeling that the current versioning scheme > > (Module::CoreList version == perl version) is problematic. Just using > > an increasing number or a date-based version number would be better. > >
> > Maybe I should outline the possible problems here: a user who installs > perl 5.20.1 and then upgrades his modules (e.g. by using CPAN.pm's > "upgrade" command) would get an *unusable* Module::CoreList. This will > break all modules depending on correct Module::CoreList information, > for example Test::Prereq > (https://rt.cpan.org/Public/Bug/Display.html?id=98445 ), modules > depending on Test::Prereq (e.g. CPAN::Mini::Tested, > Netscape::Bookmarks, Distribution::Cooker...), or Pinto > (https://github.com/thaljef/Pinto/issues/167 ). > > IMHO this should be fixed before the perl 5.20.1 release, either > within perl 5.20.1, or using a CPAN release of Module::CoreList.
One solution would be for maint release to include a completely up-to-date corelist, instead of one that has just been updated for that particular maint release. (Not only would it solve this problem; it would also reduce the hassle required to make a release, I imagine.) -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.7k
Dana Pon 08. Ruj 2014, 12:41:33, sprout reče: Show quoted text
> On Mon Sep 08 11:26:16 2014, slaven@rezic.de wrote:
> > Dana Ned 31. Kol 2014, 11:43:40, slaven@rezic.de reče: > >
> > > > > > 5.20.1-RC1 ships with Module::CoreList 5.020001, while the newest > > > on > > > CPAN is 5.021003. Unfortunately 5.21.3 came before 5.20.1, so the > > > latest version on CPAN is missing the 5.20.1 information. This is > > > already causing breakage, e.g. distributions using Test::Prereq > > > have > > > test failures. > > > > > > I have the feeling that the current versioning scheme > > > (Module::CoreList version == perl version) is problematic. Just > > > using > > > an increasing number or a date-based version number would be > > > better. > > >
> > > > Maybe I should outline the possible problems here: a user who > > installs > > perl 5.20.1 and then upgrades his modules (e.g. by using CPAN.pm's > > "upgrade" command) would get an *unusable* Module::CoreList. This > > will > > break all modules depending on correct Module::CoreList information, > > for example Test::Prereq > > (https://rt.cpan.org/Public/Bug/Display.html?id=98445 ), modules > > depending on Test::Prereq (e.g. CPAN::Mini::Tested, > > Netscape::Bookmarks, Distribution::Cooker...), or Pinto > > (https://github.com/thaljef/Pinto/issues/167 ). > > > > IMHO this should be fixed before the perl 5.20.1 release, either > > within perl 5.20.1, or using a CPAN release of Module::CoreList.
> > One solution would be for maint release to include a completely up-to- > date corelist, instead of one that has just been updated for that > particular maint release.
The corelist in the 5.20.1 release is already the most up-to-date one. It has unfortunately a lower version than the latest on CPAN.
Subject: Re: [perl #122670] Module::CoreList version problems
CC: perl5-porters [...] perl.org
To: perlbug-followup [...] perl.org
Date: Tue, 9 Sep 2014 00:59:54 +0100
From: Steve Hay <steve.m.hay [...] googlemail.com>

On 8 Sep 2014 21:16, "slaven@rezic.de via RT" <perlbug-followup@perl.org> wrote:
Show quoted text

>
> Dana Pon 08. Ruj 2014, 12:41:33, sprout reče:
> > On Mon Sep 08 11:26:16 2014, slaven@rezic.de wrote:
> > > Dana Ned 31. Kol 2014, 11:43:40, slaven@rezic.de reče:
> > >
> > > >
> > > > 5.20.1-RC1 ships with Module::CoreList 5.020001, while the newest
> > > > on
> > > > CPAN is 5.021003. Unfortunately 5.21.3 came before 5.20.1, so the
> > > > latest version on CPAN is missing the 5.20.1 information. This is
> > > > already causing breakage, e.g. distributions using Test::Prereq
> > > > have
> > > > test failures.
> > > >
> > > > I have the feeling that the current versioning scheme
> > > > (Module::CoreList version == perl version) is problematic. Just
> > > > using
> > > > an increasing number or a date-based version number would be
> > > > better.
> > > >
> > >
> > > Maybe I should outline the possible problems here: a user who
> > > installs
> > > perl 5.20.1 and then upgrades his modules (e.g. by using CPAN.pm's
> > > "upgrade" command) would get an *unusable* Module::CoreList. This
> > > will
> > > break all modules depending on correct Module::CoreList information,
> > > for example Test::Prereq
> > > (https://rt.cpan.org/Public/Bug/Display.html?id=98445 ), modules
> > > depending on Test::Prereq (e.g. CPAN::Mini::Tested,
> > > Netscape::Bookmarks, Distribution::Cooker...), or Pinto
> > > (https://github.com/thaljef/Pinto/issues/167 ).
> > >
> > > IMHO this should be fixed before the perl 5.20.1 release, either
> > > within perl 5.20.1, or using a CPAN release of Module::CoreList.
> >
> > One solution would be for maint release to include a completely up-to-
> > date corelist, instead of one that has just been updated for that
> > particular maint release.
>
> The corelist in the 5.20.1 release is already the most up-to-date one. It has unfortunately a lower version than the latest on CPAN.
>

The intention is to switch to a date-based version scheme in the future to solve this problem, but I believed that this was not a new problem and had happened before with other maint releases even prior to the current perl-version-based version scheme.
Hence I did not see the need to jump into changing things at the last minute for this release.

However, I'm now not so sure if this has happened before, at least recently. It certainly didn't happen with 5.18.1 or 5.18.2.

So maybe a fix for this release would be wise after all. A new CPAN release containing 5.20.1's data but switched to a new date-based version would save having to make an RC3, but how could it know 5.20.1's release date before that has happened?...

New Module::CoreList releases are always made immediately after a perl release anyway, so we could make *that* the one that switches numbering scheme. There would be a small window of time in which someone 'upgrading' Module::CoreList (to the older 5.021003) would be broken, but a fix would be imminent anyway so they would just need to upgrade again soon after.

That seems acceptable to me, but I'm willing to make an RC3 if the consensus favours the safer route.

Subject: Re: [perl #122670] Module::CoreList version problems
Date: Mon, 8 Sep 2014 21:54:31 -0400
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 655b
* Steve Hay <steve.m.hay@googlemail.com> [2014-09-08T19:59:54] Show quoted text
> New Module::CoreList releases are always made immediately after a perl > release anyway, so we could make *that* the one that switches numbering > scheme. There would be a small window of time in which someone 'upgrading' > Module::CoreList (to the older 5.021003) would be broken, but a fix would > be imminent anyway so they would just need to upgrade again soon after. > > That seems acceptable to me, but I'm willing to make an RC3 if the > consensus favours the safer route.
That seems okay to me, too, but taking a moment to see whether there are objections seems good... -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 155b
With the release of Module-CoreList-5.20140914 onto CPAN following the release of perl-5.20.1, am I correct in thinking that this ticket can now be closed?
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 221b
Dana Uto 16. Ruj 2014, 13:19:43, shay reče: Show quoted text
> With the release of Module-CoreList-5.20140914 onto CPAN following the > release of perl-5.20.1, am I correct in thinking that this ticket can > now be closed?
Very likely.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 328b
Dana Uto 16. Ruj 2014, 13:41:17, slaven@rezic.de reče: Show quoted text
> Dana Uto 16. Ruj 2014, 13:19:43, shay reče:
> > With the release of Module-CoreList-5.20140914 onto CPAN following the > > release of perl-5.20.1, am I correct in thinking that this ticket can > > now be closed?
> > Very likely.
Wait, 5.18.3-RC1 has the same problem.
Subject: Re: [perl #122670] Module::CoreList version problems
From: Karen Etheridge <perl [...] froods.org>
Date: Wed, 17 Sep 2014 23:17:29 -0700
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 859b
On Wed, Sep 17, 2014 at 10:57:45PM -0700, slaven@rezic.de via RT wrote: Show quoted text
> Dana Uto 16. Ruj 2014, 13:41:17, slaven@rezic.de reče:
> > Dana Uto 16. Ruj 2014, 13:19:43, shay reče:
> > > With the release of Module-CoreList-5.20140914 onto CPAN following the > > > release of perl-5.20.1, am I correct in thinking that this ticket can > > > now be closed?
> > > > Very likely.
> > Wait, 5.18.3-RC1 has the same problem.
It needs a new Module::CoreList release that contains dates for 5.18.3-RC1. Since versions aren't identified like that, you'll have to lie about the release date of 5.18.3, and then amend it with another MCL change in the final release. However, this release of MCL is not released to the cpan but is only contained in this RC, then no other perl versions will be affected. I suppose you could release it as a -TRIAL to cpan, but.. meh.
Subject: Re: [perl #122670] Module::CoreList version problems
Date: Thu, 18 Sep 2014 08:26:01 +0100
To: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: Steve Hay <steve.m.hay [...] googlemail.com>
Download (untitled) / with headers
text/plain 1.9k
On 18 September 2014 07:17, Karen Etheridge <perl@froods.org> wrote: Show quoted text
> On Wed, Sep 17, 2014 at 10:57:45PM -0700, slaven@rezic.de via RT wrote:
>> Dana Uto 16. Ruj 2014, 13:41:17, slaven@rezic.de reče:
>> > Dana Uto 16. Ruj 2014, 13:19:43, shay reče:
>> > > With the release of Module-CoreList-5.20140914 onto CPAN following the >> > > release of perl-5.20.1, am I correct in thinking that this ticket can >> > > now be closed?
>> > >> > Very likely.
>> >> Wait, 5.18.3-RC1 has the same problem.
> > It needs a new Module::CoreList release that contains dates for 5.18.3-RC1. > Since versions aren't identified like that, you'll have to lie about the > release date of 5.18.3, and then amend it with another MCL change in the > final release. > > However, this release of MCL is not released to the cpan but is only > contained in this RC, then no other perl versions will be affected. > I suppose you could release it as a -TRIAL to cpan, but.. meh. >
The MCL in 5.18.3-RC1 already has the release date for 5.18.3 filled in (although it wasn't my reading of the RMG for that to be done!), so a new CPAN release could use that date, but I don't think the -TRIAL release idea is worth the bother now that we have a plan in place to fix this anyway. Yes, the problem has occurred again with 5.18.3-RC1 because it's sticking to the old-style numbering scheme (in fact, an even older style than 5.20.1 used!), but as with the final release of 5.20.1, the problem will disappear with a new CPAN release immediately following the final release of 5.18.3, and longer term (5.22 onwards) the problem will go away with the new 5.YYYYMMDD numbering scheme. I think the only question remaining is whether maint releases of 5.18 and 5.20 should switch to the new scheme to avoid the problem with their RC releases (and for the small window of time following their final release, before the new CPAN MCL is released), or whether (as has been the case so far) they should stick with their existing 3.x and 5.02000x (respectively) numbering schemes.
From: Abigail <abigail [...] abigail.be>
Date: Thu, 18 Sep 2014 10:56:11 +0200
To: Steve Hay <steve.m.hay [...] googlemail.com>
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Subject: Re: [perl #122670] Module::CoreList version problems
Download (untitled) / with headers
text/plain 577b
On Thu, Sep 18, 2014 at 08:26:01AM +0100, Steve Hay wrote: Show quoted text
> > Yes, the problem has occurred again with 5.18.3-RC1 because it's > sticking to the old-style numbering scheme (in fact, an even older > style than 5.20.1 used!), but as with the final release of 5.20.1, the > problem will disappear with a new CPAN release immediately following > the final release of 5.18.3, and longer term (5.22 onwards) the > problem will go away with the new 5.YYYYMMDD numbering scheme.
Will a 5.YYYYMMDD scheme prevent us from doing a maint and a dev release on the same day? Abigail
Subject: Re: [perl #122670] Module::CoreList version problems
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Date: Thu, 18 Sep 2014 10:03:44 +0100
To: Abigail <abigail [...] abigail.be>
From: Steve Hay <steve.m.hay [...] googlemail.com>
Download (untitled) / with headers
text/plain 710b
On 18 September 2014 09:56, Abigail <abigail@abigail.be> wrote: Show quoted text
> On Thu, Sep 18, 2014 at 08:26:01AM +0100, Steve Hay wrote:
>> >> Yes, the problem has occurred again with 5.18.3-RC1 because it's >> sticking to the old-style numbering scheme (in fact, an even older >> style than 5.20.1 used!), but as with the final release of 5.20.1, the >> problem will disappear with a new CPAN release immediately following >> the final release of 5.18.3, and longer term (5.22 onwards) the >> problem will go away with the new 5.YYYYMMDD numbering scheme.
> > > Will a 5.YYYYMMDD scheme prevent us from doing a maint and a dev release > on the same day? >
No, but I think other logistical / will-power factors will ;-)
Subject: Re: [perl #122670] Module::CoreList version problems
Date: Thu, 18 Sep 2014 09:31:44 -0400
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 995b
* Steve Hay <steve.m.hay@googlemail.com> [2014-09-18T03:26:01] Show quoted text
> Yes, the problem has occurred again with 5.18.3-RC1 because it's > sticking to the old-style numbering scheme (in fact, an even older > style than 5.20.1 used!), but as with the final release of 5.20.1, the > problem will disappear with a new CPAN release immediately following > the final release of 5.18.3, and longer term (5.22 onwards) the > problem will go away with the new 5.YYYYMMDD numbering scheme.
My plan was that upon the release of 5.18.3, the release data for 5.18.3 would immediately be forward-ported to blead, and a release would be made immediately from that, with a new-style version. Any new-style (5.x) version will trump the 3.x in v5.18.3 :) I encountered some uninteresting problems doing other things with maint-5.18, and this seemed easiest. I expect this to be the last release of 5.18.3, but even if it isn't, we should have no problems in the future, sticking to the plan above, right? -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Subject: Re: [perl #122670] Module::CoreList version problems
From: Chris 'BinGOs' Williams <chris [...] bingosnet.co.uk>
Date: Thu, 18 Sep 2014 14:46:34 +0100
CC: perl5-porters [...] perl.org
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 1.1k
On Thu, Sep 18, 2014 at 09:31:44AM -0400, Ricardo Signes wrote: Show quoted text
> * Steve Hay <steve.m.hay@googlemail.com> [2014-09-18T03:26:01]
> > Yes, the problem has occurred again with 5.18.3-RC1 because it's > > sticking to the old-style numbering scheme (in fact, an even older > > style than 5.20.1 used!), but as with the final release of 5.20.1, the > > problem will disappear with a new CPAN release immediately following > > the final release of 5.18.3, and longer term (5.22 onwards) the > > problem will go away with the new 5.YYYYMMDD numbering scheme.
> > My plan was that upon the release of 5.18.3, the release data for 5.18.3 > would immediately be forward-ported to blead, and a release would be made > immediately from that, with a new-style version. Any new-style (5.x) version > will trump the 3.x in v5.18.3 :) > > I encountered some uninteresting problems doing other things with maint-5.18, > and this seemed easiest. > > I expect this to be the last release of 5.18.3, but even if it isn't, we should > have no problems in the future, sticking to the plan above, right? >
Sounds good to me. -- Chris Williams aka BinGOs PGP ID 0x4658671F http://www.gumbynet.org.uk ==========================
Download signature.asc
application/pgp-signature 181b

Message body not shown because it is not plain text.

From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #122670] Module::CoreList version problems
Date: Sat, 16 Dec 2017 07:47:27 +0000
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 141b
Module::CoreList is now using the date-based version number scheme, which resolves the issue described. This ticket can be closed. -zefram
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 408b
Dana Fri, 15 Dec 2017 23:47:39 -0800, zefram@fysh.org reče: Show quoted text
> Module::CoreList is now using the date-based version number scheme, > which resolves the issue described. This ticket can be closed.
The current situation is much better, though it's still not perfect. But the remaining problems are already addressed in https://rt.perl.org/Ticket/Display.html?id=127914 So I agree: this ticket may be closed.


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