From rehsack@gmail.com

Hi,

today I discussed about File​::ConfigDir with a user and this discussion
resulted in RT#101966 (https://rt.cpan.org/Public/Bug/Display.html?id=101966).

However, with perl-5.16 comes FindBin having a serious bug fixed, which might
makes it reasonable to have FindBin on CPAN to force updates in legacy
environments.

Best regards
--
Jens Rehsack
rehsack@​gmail.com

From @karenetheridge

On Fri Feb 06 07​:11​:19 2015, rehsack@​gmail.com wrote​:

However, with perl-5.16 comes FindBin having a serious bug fixed,
which might
makes it reasonable to have FindBin on CPAN to force updates in legacy
environments.

My assumption/understanding was that non-dual-lifed modules had that status if
they were so intertwined with core features that it was inpractical or
impossible to write them to work on multiple perl versions simultaneously.
This doesn't seem to be the case for FindBin, so I wholeheartedly support the
sentiment to make this a dual-life module (even if it's upstream-blead), to
facilitate having older perl installs benefit from recent bug fixes.

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

From @tonycoz

On Sun Feb 08 15​:39​:30 2015, ether wrote​:

On Fri Feb 06 07​:11​:19 2015, rehsack@​gmail.com wrote​:

However, with perl-5.16 comes FindBin having a serious bug fixed,
which might
makes it reasonable to have FindBin on CPAN to force updates in
legacy
environments.

My assumption/understanding was that non-dual-lifed modules had that
status if
they were so intertwined with core features that it was inpractical or
impossible to write them to work on multiple perl versions
simultaneously.
This doesn't seem to be the case for FindBin, so I wholeheartedly
support the
sentiment to make this a dual-life module (even if it's upstream-
blead), to
facilitate having older perl installs benefit from recent bug fixes.

There's several core-only modules that aren't tied to core and could be released as dual-life, it's really just a matter of finding volunteers who are interested in doing releases.

I think any of the following could be made dual-life​:

  ext/FileCache
  ext/File-Find
  ext/GDBM_File
  ext/I18N-LangInfo
  ext/IPC-Open3
  ext/NDBM_File
  ext/ODBM_File
  ext/PerlIO-encoding
  ext/PerlIO-mmap
  ext/PerlIO-scalar
  ext/PerlIO-via
  ext/Pod-Html
  ext/POSIX (might be a lot of work, since probing is done by Configure)
  ext/SDBM_File
  ext/Sys-Hostname
  ext/Tie-Memoize

  lib/AnyDBM_File.pm
  lib/Benchmark.pm
  lib/Class/Struct.pm
  lib/DBM_Filter.pm (etc)
  lib/DirHandle.pm
  lib/File/Basename.pm
  lib/File/Compare.pm
  lib/File/Copy.pm
  lib/FileHandle.pm
  lib/File/stat.pm
  lib/FindBin.pm
  lib/Getopt/Std.pm
  lib/Net/*ent.pm
  lib/SelectSaver.pm
  lib/Tie/*.pm
  lib/Time/gmtime.pm
  lib/Time/localtime.pm
  lib/User/*ent.pm

Making some of the lib/ modules (like File​::Copy) available on CPAN may complicate the build process a little more - we'll need to add their dist/Foo/lib directories to miniperl's search path, but that's not difficult.

Tony

From @jkeenan

On Sun Feb 08 18​:41​:05 2015, tonyc wrote​:

On Sun Feb 08 15​:39​:30 2015, ether wrote​:

On Fri Feb 06 07​:11​:19 2015, rehsack@​gmail.com wrote​:

However, with perl-5.16 comes FindBin having a serious bug fixed,
which might
makes it reasonable to have FindBin on CPAN to force updates in
legacy
environments.

My assumption/understanding was that non-dual-lifed modules had that
status if
they were so intertwined with core features that it was inpractical
or
impossible to write them to work on multiple perl versions
simultaneously.
This doesn't seem to be the case for FindBin, so I wholeheartedly
support the
sentiment to make this a dual-life module (even if it's upstream-
blead), to
facilitate having older perl installs benefit from recent bug fixes.

There's several core-only modules that aren't tied to core and could
be released as dual-life, it's really just a matter of finding
volunteers who are interested in doing releases.

Yesterday I had a go at moving FindBin from lib/ to dist/. My objective was simply to understand the mechanics of making this move, i.e., to see what would break.

I had to add a dummy entry for a CPAN distro for this in Porting/Maintainers.pl. That cleared up one failure in the porting tests.

The one error that I didn't know how to solve was this​:

#####
$ cd t; ./perl harness -v porting/regen.t; cd -

ok 1 - generated perly.act is up to date
[snip]
ok - regen/genpacksizetables.pl packsizetables.c
'lib/.gitignore-new' and 'lib/.gitignore' differ
ok # Makefile.SH is up to date
ok # win32/Makefile is up to date
ok # win32/makefile.mk is up to date
not ok - regen/lib_cleanup.pl lib/.gitignore
ok - regen/miniperlmain.pl miniperlmain.c
ok - regen/feature.pl feature.h
not ok - Porting/makemeta META.json
'META.json-new' and 'META.json' differ
'META.yml-new' and 'META.yml' differ
not ok - Porting/makemeta META.yml
Failed 3/43 subtests

Test Summary Report

porting/regen.t (Wstat​: 0 Tests​: 43 Failed​: 3)
  Failed tests​: 14, 42-43
Files=1, Tests=43, 2 wallclock secs ( 0.02 usr 0.00 sys + 1.98 cusr 0.09 csys = 2.09 CPU)
Result​: FAIL
/home/jkeenan/gitwork/perl
#####

I don't yet have a position as to whether making FindBin dual-lifed is a good idea or not.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

From @tonycoz

On Sun Feb 08 19​:15​:25 2015, jkeenan wrote​:

Yesterday I had a go at moving FindBin from lib/ to dist/. My
objective was simply to understand the mechanics of making this move,
i.e., to see what would break.

I had to add a dummy entry for a CPAN distro for this in
Porting/Maintainers.pl. That cleared up one failure in the porting
tests.

The one error that I didn't know how to solve was this​:

#####
$ cd t; ./perl harness -v porting/regen.t; cd -

ok 1 - generated perly.act is up to date
[snip]
ok - regen/genpacksizetables.pl packsizetables.c
'lib/.gitignore-new' and 'lib/.gitignore' differ
ok # Makefile.SH is up to date
ok # win32/Makefile is up to date
ok # win32/makefile.mk is up to date
not ok - regen/lib_cleanup.pl lib/.gitignore

Possibly, just run​:

  perl regen/lib_cleanup.pl

Tony

From rehsack@gmail.com

Am 09.02.2015 um 03​:41 schrieb Tony Cook via RT <perlbug-followup@​perl.org>​:

On Sun Feb 08 15​:39​:30 2015, ether wrote​:

On Fri Feb 06 07​:11​:19 2015, rehsack@​gmail.com wrote​:

However, with perl-5.16 comes FindBin having a serious bug fixed,
which might
makes it reasonable to have FindBin on CPAN to force updates in
legacy
environments.

My assumption/understanding was that non-dual-lifed modules had that
status if
they were so intertwined with core features that it was inpractical or
impossible to write them to work on multiple perl versions
simultaneously.
This doesn't seem to be the case for FindBin, so I wholeheartedly
support the
sentiment to make this a dual-life module (even if it's upstream-
blead), to
facilitate having older perl installs benefit from recent bug fixes.

There's several core-only modules that aren't tied to core and could be released as dual-life, it's really just a matter of finding volunteers who are interested in doing releases.

For a very few (max 3) I could do.
I expect it's not necessary to have separate dists for any, so ?DBM_File could be in a one dist (with or without AnyDBM...?).
Maybe Steffen could be asked to include lib/File/Basename.pm into PathTools?

I'm familiar with the POSIX backends below File/stat.pm and the */*ent.pm
CPAN POSIX.pm should receive kind of probing as Config​::AutoConf provides ...

Not that I offer volunteering here and now - but I'm open for ?DBM_File and POSIX related stuff.
Maybe that's something we (Rick) can discuss at qah in Berlin.

I think any of the following could be made dual-life​:

ext/FileCache
ext/File-Find
ext/GDBM_File
ext/I18N-LangInfo
ext/IPC-Open3
ext/NDBM_File
ext/ODBM_File
ext/PerlIO-encoding
ext/PerlIO-mmap
ext/PerlIO-scalar
ext/PerlIO-via
ext/Pod-Html
ext/POSIX (might be a lot of work, since probing is done by Configure)
ext/SDBM_File
ext/Sys-Hostname
ext/Tie-Memoize

lib/AnyDBM_File.pm
lib/Benchmark.pm
lib/Class/Struct.pm
lib/DBM_Filter.pm (etc)
lib/DirHandle.pm
lib/File/Basename.pm
lib/File/Compare.pm
lib/File/Copy.pm
lib/FileHandle.pm
lib/File/stat.pm
lib/FindBin.pm
lib/Getopt/Std.pm
lib/Net/*ent.pm
lib/SelectSaver.pm
lib/Tie/*.pm
lib/Time/gmtime.pm
lib/Time/localtime.pm
lib/User/*ent.pm

Making some of the lib/ modules (like File​::Copy) available on CPAN may complicate the build process a little more - we'll need to add their dist/Foo/lib directories to miniperl's search path, but that's not difficult.

Cheers
--
Jens Rehsack
rehsack@​gmail.com

From @jkeenan

On Sun Feb 08 21​:28​:02 2015, tonyc wrote​:

On Sun Feb 08 19​:15​:25 2015, jkeenan wrote​:

Yesterday I had a go at moving FindBin from lib/ to dist/. My
objective was simply to understand the mechanics of making this move,
i.e., to see what would break.

I had to add a dummy entry for a CPAN distro for this in
Porting/Maintainers.pl. That cleared up one failure in the porting
tests.

The one error that I didn't know how to solve was this​:

#####
$ cd t; ./perl harness -v porting/regen.t; cd -

ok 1 - generated perly.act is up to date
[snip]
ok - regen/genpacksizetables.pl packsizetables.c
'lib/.gitignore-new' and 'lib/.gitignore' differ
ok # Makefile.SH is up to date
ok # win32/Makefile is up to date
ok # win32/makefile.mk is up to date
not ok - regen/lib_cleanup.pl lib/.gitignore

Possibly, just run​:

perl regen/lib_cleanup.pl

Tony

That reduced the number of failures from 3 to 2.

#####
$ perl regen/lib_cleanup.pl
Changed​: lib/.gitignore
[perl] 108 $ cd t; ./perl harness -v porting/regen.t; cd -

ok 1 - generated perly.act is up to date
[snip]
ok - regen/feature.pl feature.h
not ok - Porting/makemeta META.json
'META.json-new' and 'META.json' differ
'META.yml-new' and 'META.yml' differ
not ok - Porting/makemeta META.yml
Failed 2/43 subtests

Test Summary Report

porting/regen.t (Wstat​: 0 Tests​: 43 Failed​: 2)
  Failed tests​: 42-43
Files=1, Tests=43, 2 wallclock secs ( 0.02 usr 0.00 sys + 1.57 cusr 0.05 csys = 1.64 CPU)
Result​: FAIL
/home/jkeenan/gitwork/perl
#####
--
James E Keenan (jkeenan@​cpan.org)

From @tonycoz

On Mon Feb 09 04​:46​:32 2015, jkeenan wrote​:

not ok - Porting/makemeta META.json
'META.json-new' and 'META.json' differ
'META.yml-new' and 'META.yml' differ
not ok - Porting/makemeta META.yml
Failed 2/43 subtests

  make regen-meta

should fix them both.

Tony

From @ap

* Jens Rehsack <rehsack@​gmail.com> [2015-02-09 10​:55]​:

I expect it's not necessary to have separate dists for any, so
?DBM_File could be in a one dist (with or without AnyDBM...?).

If you are using a particular DBM you want to be able to depend on that
specific DBM.

--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From rehsack@gmail.com

Am 11.02.2015 um 18​:40 schrieb Aristotle Pagaltzis <pagaltzis@​gmx.de>​:

* Jens Rehsack <rehsack@​gmail.com> [2015-02-09 10​:55]​:

I expect it's not necessary to have separate dists for any, so
?DBM_File could be in a one dist (with or without AnyDBM...?).

If you are using a particular DBM you want to be able to depend on that
specific DBM.

We should discuss this outside of this ticket ;)
I have a little experience with that and which OS provides you which one.
So no, particular dependencies on ?DBM_File are insane except of GDBM_File when restricted OS support ...

Cheers
--
Jens Rehsack
rehsack@​gmail.com

This would still be really great to have.

@jkeenan, maybe you could revive your efforts to do the move?

@jkeenan, maybe you could revive your efforts to do the move?

No thanks. I no longer have that code available. Even if I did, (a) there are other CPAN distros I am more concerned about from a maintenance perspective; and (b) it would be better if someone other than me took this over. This kind of maintenance work is the sort of thing that a new contributor to the Perl 5 core distribution can cut her teeth on. We have to be thinking of recruiting new people rather than asking veteran contributors to extend themselves further.

Thank you very much.
Jim Keenan

Hey. I just posted a PR to do this. It's being smoked. I put everyone here as reviewers to approve.

As far as I can tell, FindBin version 1.51 is found in both blead and perl-5.30.1. In the repository, it's found under dist/FindBin, which is appropriate for a "blead-upstream" dual life module.

However, AFAICT it has not yet received a separate CPAN release. Searching for it on metacpan points to perl-5.30.1.

Do we need to do a CPAN release before we can close this ticket? If so, who can do that?

Thank you very much.
Jim Keenan

Would it be possible to get a CPAN release of FindBin?

It's currently not viewable on metacpan because it's listed as no_index in perl, but doesn't have its own release.

As far as I can tell, FindBin version 1.51 is found in both blead and perl-5.30.1. In the repository, it's found under dist/FindBin, which is appropriate for a "blead-upstream" dual life module.

However, AFAICT it has not yet received a separate CPAN release. Searching for it on metacpan points to perl-5.30.1.

Do we need to do a CPAN release before we can close this ticket? If so, who can do that?

Thank you very much.
Jim Keenan

@xsawyerx, can you handle this upstream release of FindBin?

Thank you very much.
Jim Keenan

This has been handled by @toddr https://metacpan.org/release/TODDR/FindBin-1.52

This has been handled by @toddr https://metacpan.org/release/TODDR/FindBin-1.52

Thanks. Closing ticket.