Module::CoreList version problems #14060

p5pRT · 2014-08-31T18:43:40Z

Migrated from rt.perl.org#122670 (status was 'resolved')

Searchable as RT122670$

p5pRT · 2014-08-31T18:43:40Z

From @eserte

Created by @eserte

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.

Perl Info


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

p5pRT · 2014-09-08T18:26:16Z

From @eserte

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 (thaljef/Pinto#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.

p5pRT · 2014-09-08T18:26:16Z

From [Unknown Contact. See original ticket]

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 (thaljef/Pinto#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.

p5pRT · 2014-09-08T19:41:33Z

From @cpansprout

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
(thaljef/Pinto#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

p5pRT · 2014-09-08T19:41:33Z

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

p5pRT · 2014-09-08T20:16:20Z

From @eserte

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
(thaljef/Pinto#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.

p5pRT · 2014-09-09T00:00:34Z

From @steve-m-hay

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

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
(thaljef/Pinto#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.

p5pRT · 2014-09-09T01:54:57Z

From @rjbs

* Steve Hay <steve.m.hay@googlemail.com> [2014-09-08T19:59:54]

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

p5pRT · 2014-09-16T20:19:43Z

From @steve-m-hay

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?

p5pRT · 2014-09-16T20:19:43Z

From [Unknown Contact. See original ticket]

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?

p5pRT · 2014-09-16T20:41:17Z

From @eserte

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.

p5pRT · 2014-09-18T05:57:44Z

From @eserte

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.

p5pRT · 2014-09-18T06:17:59Z

From @karenetheridge

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.

p5pRT · 2014-09-18T07:26:26Z

From @steve-m-hay

On 18 September 2014 07:17, Karen Etheridge <perl@froods.org> wrote:

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.

p5pRT · 2014-09-18T08:56:44Z

From @Abigail

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?

Abigail

p5pRT · 2014-09-18T09:04:17Z

From @steve-m-hay

On 18 September 2014 09:56, Abigail <abigail@abigail.be> wrote:

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 ;-)

p5pRT · 2014-09-18T13:32:24Z

From @rjbs

* 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?

--
rjbs

p5pRT · 2014-09-18T13:47:14Z

From @bingos

On Thu, Sep 18, 2014 at 09:31:44AM -0400, Ricardo Signes wrote:

* 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

p5pRT · 2017-12-16T07:47:39Z

From zefram@fysh.org

Module::CoreList is now using the date-based version number scheme,
which resolves the issue described. This ticket can be closed.

-zefram

p5pRT · 2017-12-16T08:13:05Z

From @eserte

Dana Fri, 15 Dec 2017 23:47:39 -0800, zefram@fysh.org reče:

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-archive.perl.org/perl5/Ticket/Display.html?id=127914

So I agree: this ticket may be closed.

p5pRT · 2017-12-18T12:06:15Z

@iabyn - Status changed from 'open' to 'resolved'

p5pRT closed this Dec 18, 2017

p5pRT added Severity Medium affects-5.20 distro-freebsd type-library labels Oct 19, 2019

Perl / perl5

Module::CoreList version problems #14060

Module::CoreList version problems #14060

p5pRT commented Aug 31, 2014

p5pRT commented Aug 31, 2014

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

p5pRT commented Sep 9, 2014

p5pRT commented Sep 9, 2014

p5pRT commented Sep 16, 2014

p5pRT commented Sep 16, 2014

p5pRT commented Sep 16, 2014

p5pRT commented Sep 18, 2014

p5pRT commented Sep 18, 2014

p5pRT commented Sep 18, 2014

p5pRT commented Sep 18, 2014

p5pRT commented Sep 18, 2014

p5pRT commented Sep 18, 2014

p5pRT commented Sep 18, 2014

p5pRT commented Dec 16, 2017

p5pRT commented Dec 16, 2017

p5pRT commented Dec 18, 2017

Perl / perl5

Join GitHub today

Module::CoreList version problems #14060

Module::CoreList version problems #14060

Comments

p5pRT commented Aug 31, 2014

p5pRT commented Aug 31, 2014

From @eserte

Created by @eserte

p5pRT commented Sep 8, 2014

From @eserte

p5pRT commented Sep 8, 2014

From [Unknown Contact. See original ticket]

p5pRT commented Sep 8, 2014

From @cpansprout

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

From @eserte

p5pRT commented Sep 9, 2014

From @steve-m-hay

p5pRT commented Sep 9, 2014

From @rjbs

p5pRT commented Sep 16, 2014

From @steve-m-hay

p5pRT commented Sep 16, 2014

From [Unknown Contact. See original ticket]

p5pRT commented Sep 16, 2014

From @eserte

p5pRT commented Sep 18, 2014

From @eserte

p5pRT commented Sep 18, 2014

From @karenetheridge

p5pRT commented Sep 18, 2014

From @steve-m-hay

p5pRT commented Sep 18, 2014

From @Abigail

p5pRT commented Sep 18, 2014

From @steve-m-hay

p5pRT commented Sep 18, 2014

From @rjbs

p5pRT commented Sep 18, 2014

From @bingos

-- Chris Williams aka BinGOs PGP ID 0x4658671F http​://www.gumbynet.org.uk

p5pRT commented Dec 16, 2017

From zefram@fysh.org

p5pRT commented Dec 16, 2017

From @eserte

p5pRT commented Dec 18, 2017

--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk