Bug #118598 for Net-DNS: Serious Makefile.PL issues

Wed Nov 02 20:50:51 2016 ether [...] cpan.org - Ticket created

Subject:

Serious Makefile.PL issues

I ran into https://rt.cpan.org/Ticket/Display.html?id=108908 while upgrading a suite of machines running in the cloud. Thankfully the installation broke and halted before the systems were rotated into service and brought our systems down, but this highlights that there are still serious issues outstanding with the Makefile.PL. While investigating and writing a local patch, I also discovered: - strict, warnings are not active in Makefile.PL, allowing other issues to slip through unnoticed; - modules are used as barewords without quoting; - versions are used as numbers rather than strings, leading to a loss of trailing zeros (which can sometimes be significant); - WriteMakefile() is called more than once, meaning all local overrides (such as the ones you already have in place, to MY::postamble, and the one I had to add, to MY::install) would not take effect Is there a git repository against which I can write and submit patches?

Wed Nov 02 20:52:49 2016 ether [...] cpan.org - Correspondence added

Also, you seem to be making a hodge-podge attempt to add optional prereqs (this seems to be the purpose of calling WriteMakefile() twice, although there are no comments providing enlightenment), but this is done completely wrong. There is actually a proper way to declare optional prereqs to ExtUtils::MakeMaker which I can also fix.

Thu Nov 03 06:45:47 2016 NLNETLABS [...] cpan.org - Correspondence added

On Wed Nov 02 20:50:51 2016, ETHER wrote: Show quoted text

> Is there a git repository against which I can write and submit > patches?

We work on a subversion repository: https://www.net-dns.org/svn/net-dns/trunk/ For my own convenience I do have a git version of this repository. I can push it to my own github account if you want to, but don't expect it to stay there or keep in sync. https://github.com/wtoorop/Net-DNS

Thu Nov 03 06:45:50 2016 The RT System itself - Status changed from 'new' to 'open'

Sat Nov 05 17:02:26 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Wed Nov 02 20:50:51 2016, ETHER wrote: Show quoted text

> I ran into https://rt.cpan.org/Ticket/Display.html?id=108908 while > upgrading a suite of machines running in the cloud. Thankfully the > installation broke and halted before the systems were rotated into > service and brought our systems down, but this highlights that there > are still serious issues outstanding with the Makefile.PL. > > While investigating and writing a local patch, I also discovered: > > - strict, warnings are not active in Makefile.PL, allowing other > issues to slip through unnoticed; > - modules are used as barewords without quoting;

I have no quarrel with making this strict. Warnings presupposes perl 5.6 which is a tighter constraint than the declared MIN_PERL_VERSION => 5.004_04. An occasional perl -W Makefile.PL is also considerably more effective, unconditionally turning on all warnings throughout (including ExtUtils::MakeMaker and its dependencies). Show quoted text

> - versions are used as numbers rather than strings, leading to a loss > of trailing zeros (which can sometimes be significant);

The documentation for Exporter clearly states that a number is required, and I quote: Module Version Checking The Exporter module will convert an attempt to import a number from a module into a call to "$module_name->VERSION($value)". This can be used to validate that the version of the module being used is greater than or equal to the required version. For historical reasons, Exporter supplies a "require_version" method that simply delegates to "VERSION". Originally, before "UNIVERSAL::VERSION" existed, Exporter would call "require_version". Since the "UNIVERSAL::VERSION" method treats the $VERSION number as a simple numeric value it will regard version 1.10 as lower than 1.9. For this reason it is strongly recommended that you use numbers with at least two decimal places, e.g., 1.09. Show quoted text

> - WriteMakefile() is called more than once, meaning all local > overrides (such as the ones you already have in place, to > MY::postamble, and the one I had to add, to MY::install) would not > take effect

The horrible reason for that has now gone away and it was removed in 1.06_02 If we are going to build on the RT#108908 discussion, perhaps we need to recognise three different (and in some ways incompatible) groups of users. 1) Hands-on users who can be expected to read and act upon warnings and error messages. 2) Automated testers who can reasonably demand that Makefile.PL will always yield a workable Makefile. This group never does "make install". A hard stop at "perl Makefile.PL" time is unacceptable. 3) Minimally supervised scripted installers who demand an informative message and hard stop if the upgrade package will be hidden by the existing version. Human intervention would then be required to complete the process. It was clear from the discussion that modifying the installation environment or automated deletion of conflicting packages would be viewed by some as hostile acts. The simplest improvement would seem to be a modified Makefile with a dummy "install" target which spits out an appropriate message and aborts the process.

Mon Nov 07 18:33:26 2016 ether [...] cpan.org - Correspondence added

On 2016-11-05 14:02:26, rwfranks@acm.org wrote: Show quoted text

> On Wed Nov 02 20:50:51 2016, ETHER wrote:

Show quoted text

> > - versions are used as numbers rather than strings, leading to a loss > > of trailing zeros (which can sometimes be significant);

> > The documentation for Exporter clearly states that a number is > required, and I quote: > > Module Version Checking > The Exporter module will convert an attempt to import a number from > a > module into a call to "$module_name->VERSION($value)". This can be > used to > validate that the version of the module being used is greater than > or > equal to the required version. > > For historical reasons, Exporter supplies a "require_version" method > that > simply delegates to "VERSION". Originally, before "UNIVERSAL::VERSION" > existed, Exporter would call "require_version". > > Since the "UNIVERSAL::VERSION" method treats the $VERSION number as a > simple numeric value it will regard version 1.10 as lower than 1.9. > For > this reason it is strongly recommended that you use numbers with at > least > two decimal places, e.g., 1.09.

You're misinterpreting the documentation. It's saying that the value must be able to be evaluated numerically, not that it is a literal number without quotes. ExtUtils::MakeMaker preserves the stringy nature of versions that are passed to it, so for example "Foo" => "1.90" will show up in META.json as "Foo":"1.90", but "Foo" => 1.90 (note, this is a literal number) will lose its trailing zero, showing up in META.json as "Foo":"1.9". The numbers are numerically identical, but the difference can occasionally confuse humans or static inspection tools. Further information about versions can be found in CPAN::Meta::Spec -- https://metacpan.org/pod/CPAN::Meta::Spec#VERSION-NUMBERS. Thanks for the github repo -- I'll use it as the basis for a few patches that I'll send this week!

Tue Nov 08 14:50:32 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Mon Nov 07 18:33:26 2016, ETHER wrote: Show quoted text

> On 2016-11-05 14:02:26, rwfranks@acm.org wrote:

> > On Wed Nov 02 20:50:51 2016, ETHER wrote:

> > > - versions are used as numbers rather than strings, leading to a > > > loss > > > of trailing zeros (which can sometimes be significant);

> > > > The documentation for Exporter clearly states that a number is > > required, and I quote: > > > > Module Version Checking > > The Exporter module will convert an attempt to import a number from > > a > > module into a call to "$module_name->VERSION($value)". This can be > > used to > > validate that the version of the module being used is greater than > > or > > equal to the required version. > > > > For historical reasons, Exporter supplies a "require_version" method > > that > > simply delegates to "VERSION". Originally, before > > "UNIVERSAL::VERSION" > > existed, Exporter would call "require_version". > > > > Since the "UNIVERSAL::VERSION" method treats the $VERSION number as a > > simple numeric value it will regard version 1.10 as lower than 1.9. > > For > > this reason it is strongly recommended that you use numbers with at > > least > > two decimal places, e.g., 1.09.

> > You're misinterpreting the documentation. It's saying that the value > must be > able to be evaluated numerically, not that it is a literal number > without > quotes.

I am not misinterpreting the documentation, which says what happens if I import a number. Show quoted text

> ExtUtils::MakeMaker preserves the stringy nature of versions > that are > passed to it, so for example "Foo" => "1.90" will show up in META.json > as > "Foo":"1.90", but "Foo" => 1.90 (note, this is a literal number) will > lose its > trailing zero, showing up in META.json as "Foo":"1.9". The numbers are > numerically identical, but the difference can occasionally confuse > humans or > static inspection tools.

We are supplying a number which ends up unmolested in $required_version on one side of the numerical comparison. ExtUtils::MakeMaker provides the other side in $pr_version which it obtains from parsing the module source. This is different from Exporter's import method which (indirectly) uses the $VERSION variable as is. This comes unstuck with $VERSION = "1.06_04", which is overcome by doing $VERSION = eval $VERSION in DNS.pm; Both Net::DNS and Net::DNS::SEC are internally very picky about versions of dependencies to steer round bugs and lack of required features. By using numbers throughout, we are ensuring that there is little risk of a discrepancy between the versions that MakeMaker lets through and the version comparison done by the UNIVERSAL::VERSION method which underpins Exporter's import(). All of this has been proven to work on all perls from 5.004_04 to 5.25.6 so it will not be changed without a compelling reason and after a great deal of thought. Show quoted text

> > Further information about versions can be found in CPAN::Meta::Spec -- > https://metacpan.org/pod/CPAN::Meta::Spec#VERSION-NUMBERS. > > > Thanks for the github repo -- I'll use it as the basis for a few > patches that > I'll send this week!

There is a batch of patches already in the pipe. The Makefile now blows out at "make install" time when it detects an incompatible old version in the perl library. Please let us know if this meets your need, or requires further work.

Tue Nov 08 15:16:22 2016 ether [...] cpan.org - Correspondence added

On 2016-11-08 11:50:32, rwfranks@acm.org wrote: Show quoted text

> On Mon Nov 07 18:33:26 2016, ETHER wrote:

Show quoted text

> By using numbers throughout, we are ensuring that there is little risk > of a discrepancy between the versions that MakeMaker lets through and > the version comparison done by the UNIVERSAL::VERSION method which > underpins Exporter's import(). > > All of this has been proven to work on all perls from 5.004_04 to > 5.25.6 so it will not be changed without a compelling reason and after > a great deal of thought.

All I'm saying is that versions used in PREREQ_PM (etc) in Makefile.PL should be declared with quotes, rather than as bare numbers, and the same for $VERSION assignments in modules. That is, this: # Makefile.PL ... PREREQ_PM => { 'Some::Module' => '1.90' }, # Foo.pm: our $VERSION = '1.90'; is better than this: # Makefile.PL ... PREREQ_PM => { 'Some::Module' => 1.90 }, # Foo.pm: our $VERSION = 1.90;

Tue Nov 08 15:23:43 2016 ether [...] cpan.org - Correspondence added

On 2016-11-08 11:50:32, rwfranks@acm.org wrote: Show quoted text

> There is a batch of patches already in the pipe. > > The Makefile now blows out at "make install" time when it detects an > incompatible old version in the perl library. Please let us know if > this meets your need, or requires further work.

It's definitely better than what's in the current release. However, even better still would be to either delete the old installed files in $(DESTINSTALLSITEARCH), or to switch to installing the new files into $(DESTINSTALLSITEARCH) (which will overwrite the old ones). The latter might be preferrable as it removes the chance that other files (not belonging to this distribution) might be inadvertently removed.

Wed Nov 09 09:24:10 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Tue Nov 08 15:23:43 2016, ETHER wrote: Show quoted text

> On 2016-11-08 11:50:32, rwfranks@acm.org wrote:

> > > > The Makefile now blows out at "make install" time when it detects an > > incompatible old version in the perl library. Please let us know if > > this meets your need, or requires further work.

> > It's definitely better than what's in the current release. >

OK, that is where we go in 1.07, subject as always to no ill effects. Show quoted text

> However, even better still would be to either delete the old installed > files in $(DESTINSTALLSITEARCH)

Luis Muñoz characterised unilateral modification of the execution environment as a hostile act. (RT#108908) Show quoted text

> ... or to switch to installing the new files into > $(DESTINSTALLSITEARCH) (which will overwrite the old ones). The > latter might > be preferrable as it removes the chance that other files (not > belonging to > this distribution) might be inadvertently removed.

That may seem an attractive way to get past 1.01, but subsequent upgrades are then hampered by the newer version now in the "wrong" place and not so readily detectable. If that obstacle can be overcome, the state of the perl library will forever be different from that produced by a clean install.

Wed Nov 09 14:39:04 2016 ether [...] cpan.org - Correspondence added

On 2016-11-09 06:24:10, rwfranks@acm.org wrote: Show quoted text

> On Tue Nov 08 15:23:43 2016, ETHER wrote:

> > ... or to switch to installing the new files into > > $(DESTINSTALLSITEARCH) (which will overwrite the old ones). The > > latter might > > be preferrable as it removes the chance that other files (not > > belonging to > > this distribution) might be inadvertently removed.

> > That may seem an attractive way to get past 1.01, but subsequent > upgrades are then hampered by the newer version now in the "wrong" > place and not so readily detectable. > > If that obstacle can be overcome, the state of the perl library will > forever be different from that produced by a clean install.

I don't understand what you mean. I'm not saying to install into $(DESTINSTALLSITEARCH) if an old version is detected -- but use that install location regardless of if it's an upgrade or a fresh clean install. That directory is in $PERL5LIB and is discoverable.

Thu Nov 10 14:34:57 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Wed Nov 09 14:39:04 2016, ETHER wrote: Show quoted text

> On 2016-11-09 06:24:10, rwfranks@acm.org wrote:

> > On Tue Nov 08 15:23:43 2016, ETHER wrote:

> > > ... or to switch to installing the new files into > > > $(DESTINSTALLSITEARCH) (which will overwrite the old ones). The > > > latter might > > > be preferrable as it removes the chance that other files (not > > > belonging to > > > this distribution) might be inadvertently removed.

> > > > That may seem an attractive way to get past 1.01, but subsequent > > upgrades are then hampered by the newer version now in the "wrong" > > place and not so readily detectable. > > > > If that obstacle can be overcome, the state of the perl library will > > forever be different from that produced by a clean install.

> > I don't understand what you mean. I'm not saying to install into > $(DESTINSTALLSITEARCH) if an old version is detected -- but use that install > location regardless of if it's an upgrade or a fresh clean install. That > directory is in $PERL5LIB and is discoverable.

You are seeing only part of the overall picture. Historically, Net::DNS::SEC was clumsily installed by injecting DNSSEC RRs and other stuff into an existing Net::DNS installation leaving a nasty mess which is certain to upset some upgrade tool somewhere. The secondary goal is to encourage that wreckage to disappear. Your proposal would probably do a good job on the components which will be overwritten, but leave non-matching bits of Net::DNS::SEC trapped in the works. The generated Makefile now has its install bits chopped off when an old version is detected. Makefile is still good for build and test which will allow smokerboxes to carry on business as usual.

Mon Dec 26 13:49:01 2016 LEONT [...] cpan.org - Correspondence added

On Sat Nov 05 17:02:26 2016, rwfranks@acm.org wrote: Show quoted text

> I have no quarrel with making this strict. > > Warnings presupposes perl 5.6 which is a tighter constraint than the > declared MIN_PERL_VERSION => 5.004_04. > > An occasional perl -W Makefile.PL is also considerably more effective, > unconditionally turning on all warnings throughout (including > ExtUtils::MakeMaker and its dependencies).

The toolchain has dropped <5.6 support 9 years ago. A number of your dependencies don't support such systems either. Pretending your module still installs on such a system is not in any way realistic. Show quoted text

> > - versions are used as numbers rather than strings, leading to a loss > > of trailing zeros (which can sometimes be significant);

> > The documentation for Exporter clearly states that a number is > required, and I quote:

Exporter is not the place where versions are documented. There are many versions that are problematic, 0.000001 being the most trivial one (it stringifies to "0e-6" which isn't a valid version). Writing them as strings is a better default because you don't have to worry about all those edge cases, though none of the versions you're dealing with here is problematic in this sense. Show quoted text

> If we are going to build on the RT#108908 discussion, perhaps we need > to recognise three different (and in some ways incompatible) groups of > users. > > 1) Hands-on users who can be expected to read and act upon warnings > and error messages. > > 2) Automated testers who can reasonably demand that Makefile.PL will > always yield a workable Makefile. This group never does "make > install". A hard stop at "perl Makefile.PL" time is unacceptable.

I don't think you can make the assumption that they will never run make install (in particular not when Net::DNS is used as a dependency for something else). It seems to depend on the smoker. Show quoted text

> 3) Minimally supervised scripted installers who demand an informative > message and hard stop if the upgrade package will be hidden by the > existing version. Human intervention would then be required to > complete the process.

I think you're skipping a step there; What they need is not end up with a broken system, adding a hard stop merely one way way of achieving that. I very much believe that this working out of the box is much preferable, if only because this group of users may well be the largest of the three. Leon

Mon Dec 26 19:45:45 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Mon Dec 26 13:49:01 2016, LEONT wrote: Show quoted text

> On Sat Nov 05 17:02:26 2016, rwfranks@acm.org wrote:

> > I have no quarrel with making this strict. > > > > Warnings presupposes perl 5.6 which is a tighter constraint than the > > declared MIN_PERL_VERSION => 5.004_04. > > > > An occasional perl -W Makefile.PL is also considerably more > > effective, > > unconditionally turning on all warnings throughout (including > > ExtUtils::MakeMaker and its dependencies).

> > The toolchain has dropped <5.6 support 9 years ago. A number of your > dependencies don't support such systems either. Pretending your module > still installs on such a system is not in any way realistic. >

> > > - versions are used as numbers rather than strings, leading to a > > > loss > > > of trailing zeros (which can sometimes be significant);

> > > > The documentation for Exporter clearly states that a number is > > required, and I quote:

> > Exporter is not the place where versions are documented. There are > many versions that are problematic, 0.000001 being the most trivial > one (it stringifies to "0e-6" which isn't a valid version). Writing > them as strings is a better default because you don't have to worry > about all those edge cases, though none of the versions you're dealing > with here is problematic in this sense.

In which case this is not an issue. Show quoted text

> > If we are going to build on the RT#108908 discussion, perhaps we need > > to recognise three different (and in some ways incompatible) groups > > of > > users. > > > > 1) Hands-on users who can be expected to read and act upon warnings > > and error messages. > > > > 2) Automated testers who can reasonably demand that Makefile.PL will > > always yield a workable Makefile. This group never does "make > > install". A hard stop at "perl Makefile.PL" time is unacceptable.

> > I don't think you can make the assumption that they will never run > make install (in particular not when Net::DNS is used as a dependency > for something else). It seems to depend on the smoker. >

> > 3) Minimally supervised scripted installers who demand an informative > > message and hard stop if the upgrade package will be hidden by the > > existing version. Human intervention would then be required to > > complete the process.

> > I think you're skipping a step there; What they need is not end up > with a broken system, adding a hard stop merely one way way of > achieving that. I very much believe that this working out of the box > is much preferable, if only because this group of users may well be > the largest of the three.

The more convincing arguments came from those in favour of a hard stop.

Thu Dec 29 13:12:12 2016 DBOOK [...] cpan.org - Cc DBOOK added

Fri Dec 30 04:36:04 2016 NLNETLABS [...] cpan.org - Correspondence added

Addressed in 1.07

Fri Dec 30 04:36:04 2016 NLNETLABS [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Dec 30 15:23:32 2016 DBOOK [...] cpan.org - Correspondence added

On Mon Dec 26 19:45:45 2016, rwfranks@acm.org wrote: Show quoted text

> On Mon Dec 26 13:49:01 2016, LEONT wrote:

> > On Sat Nov 05 17:02:26 2016, rwfranks@acm.org wrote:

> > > I have no quarrel with making this strict. > > > > > > Warnings presupposes perl 5.6 which is a tighter constraint than the > > > declared MIN_PERL_VERSION => 5.004_04. > > > > > > An occasional perl -W Makefile.PL is also considerably more > > > effective, > > > unconditionally turning on all warnings throughout (including > > > ExtUtils::MakeMaker and its dependencies).

> > > > The toolchain has dropped <5.6 support 9 years ago. A number of your > > dependencies don't support such systems either. Pretending your module > > still installs on such a system is not in any way realistic.

Please address this. Warnings are standard. Show quoted text

> >

> > > > - versions are used as numbers rather than strings, leading to a > > > > loss > > > > of trailing zeros (which can sometimes be significant);

> > > > > > The documentation for Exporter clearly states that a number is > > > required, and I quote:

> > > > Exporter is not the place where versions are documented. There are > > many versions that are problematic, 0.000001 being the most trivial > > one (it stringifies to "0e-6" which isn't a valid version). Writing > > them as strings is a better default because you don't have to worry > > about all those edge cases, though none of the versions you're dealing > > with here is problematic in this sense.

> > In which case this is not an issue. >

It is an issue, and it will bite you, whether because of your dependency versions or your own version. Moreover, it sets a bad example to specify numeric version literals. Along the same lines, the line you added to check for an older version of Net::DNS is not quite correct. The proper way to check for a certain version of a module is with the ->VERSION() method and a stringy version number. Here is how I would do it. use constant NOINSTALL => eval { require Net::DNS; 1 } && !eval { Net::DNS->VERSION('1.00'); 1 }; Please understand that we are not idly making up problems here, these issues are all based on our extensive experience with problems that occur throughout the history of the toolchain and hundreds of strange corner cases. Would you like to reopen this issue for the remaining unsolved issues, or would you like me to open another new issue?

Fri Dec 30 15:40:35 2016 DBOOK [...] cpan.org - Correspondence added

On Fri Dec 30 15:23:32 2016, DBOOK wrote: Show quoted text

> Along the same lines, the line you added to check for an older version > of Net::DNS is not quite correct. The proper way to check for a > certain version of a module is with the ->VERSION() method and a > stringy version number. Here is how I would do it. > > use constant NOINSTALL => eval { require Net::DNS; 1 } && !eval { > Net::DNS->VERSION('1.00'); 1 };

By the way, the documentation for this method is here: https://metacpan.org/pod/UNIVERSAL#VERSION-REQUIRE

Fri Dec 30 18:23:59 2016 DBOOK [...] cpan.org - Correspondence added

The closest thing to documentation that versions should be specified as strings would be these two sections. https://metacpan.org/pod/ExtUtils::MakeMaker#VERSION_FROM https://metacpan.org/pod/CPAN::Meta::Spec#Version-Formats In particular from the latter: Version numbers must be treated as strings, not numbers. For example, 1.200 must not be serialized as 1.2. Version comparison should be delegated to the Perl version module, version 0.80 or newer. (The ->VERSION() method does use version.pm for comparison.)

Sat Dec 31 07:58:36 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Fri Dec 30 18:23:59 2016, DBOOK wrote: Show quoted text

> The closest thing to documentation that versions should be specified > as strings would be these two sections. > > https://metacpan.org/pod/ExtUtils::MakeMaker#VERSION_FROM > https://metacpan.org/pod/CPAN::Meta::Spec#Version-Formats > > In particular from the latter: > > Version numbers must be treated as strings, not numbers. For example, > 1.200 must not be serialized as 1.2. Version comparison should be > delegated to the Perl version module, version 0.80 or newer. > > (The ->VERSION() method does use version.pm for comparison.)

This is a deliberate design choice intended to satisfy the (various) needs of all the versions of ExtUtils::MakeMaker that this Makefile.PL is every likely to encounter. Pontificating based on what 5.24.0 and MakeMaker 7.10_01 does or does not do, provides no insight into the general portability issues. Neither can you assume that every user is using recent versions of perl, tools or OS. Industrial users, in particular, are reluctant to change anything that still works unless there is good (i.e. economic) reason to do so. Some industrial kit runs truly antique versions of software. Before you pursue this argument further, I suggest you inspect the versions of perl bundled with old but still supported versions of Debian, RHEL and CentOS. Not everything in the garden is as neat and tidy as you might suppose.

Sat Dec 31 15:32:16 2016 DBOOK [...] cpan.org - Correspondence added

On Sat Dec 31 07:58:36 2016, rwfranks@acm.org wrote: Show quoted text

> On Fri Dec 30 18:23:59 2016, DBOOK wrote:

> > The closest thing to documentation that versions should be specified > > as strings would be these two sections. > > > > https://metacpan.org/pod/ExtUtils::MakeMaker#VERSION_FROM > > https://metacpan.org/pod/CPAN::Meta::Spec#Version-Formats > > > > In particular from the latter: > > > > Version numbers must be treated as strings, not numbers. For example, > > 1.200 must not be serialized as 1.2. Version comparison should be > > delegated to the Perl version module, version 0.80 or newer. > > > > (The ->VERSION() method does use version.pm for comparison.)

> > This is a deliberate design choice intended to satisfy the (various) > needs of all the versions of ExtUtils::MakeMaker that this Makefile.PL > is every likely to encounter. > > Pontificating based on what 5.24.0 and MakeMaker 7.10_01 does or does > not do, provides no insight into the general portability issues. > > Neither can you assume that every user is using recent versions of > perl, tools or OS. Industrial users, in particular, are reluctant to > change anything that still works unless there is good (i.e. economic) > reason to do so. Some industrial kit runs truly antique versions of > software. > > Before you pursue this argument further, I suggest you inspect the > versions of perl bundled with old but still supported versions of > Debian, RHEL and CentOS. Not everything in the garden is as neat and > tidy as you might suppose.

Support of these ancient versions is EXACTLY why versions should be specified as we have discussed.

Sun Jan 01 06:49:23 2017 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Sat Dec 31 15:32:16 2016, DBOOK wrote: Show quoted text

> > > > Before you pursue this argument further, I suggest you inspect the > > versions of perl bundled with old but still supported versions of > > Debian, RHEL and CentOS. Not everything in the garden is as neat and > > tidy as you might suppose.

> > Support of these ancient versions is EXACTLY why versions should be > specified as we have discussed.

Karen Etheridge covered all of these points earlier in this thread; you have contributed absolutely nothing that has not already been discussed, and certainly no evidence indicating a real problem. Current design has been tested on every version from 4.004_04 to 24.0

Sun Jan 01 09:41:39 2017 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Sun Jan 01 06:49:23 2017, rwfranks@acm.org wrote: Show quoted text

> Current design has been tested on every version from 4.004_04 to 24.0

correction: 5.004_04

Sun Jan 01 14:07:25 2017 ether [...] cpan.org - Correspondence added

On 2017-01-01 03:49:23, rwfranks@acm.org wrote: Show quoted text

> On Sat Dec 31 15:32:16 2016, DBOOK wrote: >

> > > > > > Before you pursue this argument further, I suggest you inspect the > > > versions of perl bundled with old but still supported versions of > > > Debian, RHEL and CentOS. Not everything in the garden is as neat > > > and > > > tidy as you might suppose.

> > > > Support of these ancient versions is EXACTLY why versions should be > > specified as we have discussed.

> > Karen Etheridge covered all of these points earlier in this thread;

The points are being repeated now because you are still refusing to act on them.

Sun Jan 01 15:29:19 2017 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Sun Jan 01 14:07:25 2017, ETHER wrote: Show quoted text

> > The points are being repeated now because you are still refusing to > act on them.

The version numbers are entirely under my control, and are a private communication between Makefile.PL and the local ExtUtils::MakeMaker of whatever vintage. These numbers never come into direct contact with any other component in the tool chain. The only assumption that I am relying upon, is that ExtUtils::MakeMaker will continue to keep its side of the bargain. If you consider my design is incorrect, then the onus is on you, as detractors, to support your argument by providing a repeatable scenario which demonstrates a failure. Unless and until somebody produces some hard evidence to the contrary, I shall restate my belief that the design is correct or, at the very least, adequate.