Skip Menu |

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 50948
Status: resolved
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: dagolden [...] cpan.org
rafl [...] debian.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: 0.36



Subject: warning from CPAN.pm due to duplicate mentioning of dependencies
When installing Module::Build from the CPAN shell, this happens: Creating new 'Build' script for 'Module-Build' version '0.34' (/home/rafl/.perl/bin/perl Makefile.PL exited with 0) Warning: PREREQ_PM mentions Test::Harness more than once, last mention wins at CPAN/Distribution.pm line 2815, <GEN1434> line 1. It's caused by reporting the Test::Harness dependency twice, once as a build requirement, once as a normal one. I'm unsure how this should be fixed. Module::Build could drop the less-specific dependency. It could also, as it is its own build-tool, only report the most-specific version of a dependency in PREREQ_PM. Alternatively, CPAN could simply pick the most specific dependency for a given module, if something is reported twice.
Note: this is limited to users setting preferred_installer to EUMM. There are people expecting that this option will go away. I don't know, I have my sympathy for the option but of course such bugs just help to promote the use of Module::Build. It's a MakeMaker limitation that it does not report "build_requires" separately from "requires". So I would say CPAN should err on the cautious side and treat both mention as a "requires". I have checked in a (quite undertested) fix for this. Thank you:)
Subject: Re: [rt.cpan.org #47774] warning from CPAN.pm due to duplicate mentioning of dependencies
Date: Fri, 10 Jul 2009 14:08:22 -0500
To: bug-Module-Build [...] rt.cpan.org, andk [...] cpan.org
From: Ken Williams <kenahoo [...] gmail.com>
On Fri, Jul 10, 2009 at 1:17 PM, Andreas Koenig via RT<bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> It's a MakeMaker limitation that it does not report "build_requires" > separately from "requires". So I would say CPAN should err on the > cautious side and treat both mention as a "requires".
Our philosophy for dealing with the two kinds of requirements is that everything in 'requires' is also needed during 'build' time (which also includes test time), on the assumption that all parts of a distribution will be tested in the tests, so all the run-time dependencies should also be testing-time dependencies. Therefore the 'build_requires' requirements should always add to (or override) the 'requires' entries for stuff going on during build time. It's a little weird for us to have the same key in 'requires' and 'build_requires', actually. On the surface it's fine - to use the code, you only need Test::Harness (any version) installed, but during testing you need at least 3.16 installed. But how's a user supposed to deal with that in practice? Assuming they actually want to run the tests, they need 3.16 installed. If they don't plan to use at least 3.16 at run time, that means they'd be using a previous version at runtime than the one they tested with, which seems inadvisable. Perhaps we should just make Test::Harness 3.16 a normal 'requires' prereq and take it out of 'build_requires'. -Ken
Subject: Re: [rt.cpan.org #47774] warning from CPAN.pm due to duplicate mentioning of dependencies
Date: Sat, 11 Jul 2009 07:11:57 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Fri, Jul 10, 2009 at 3:08 PM, Ken Williams via RT<bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> Perhaps we should just make Test::Harness 3.16 a normal 'requires' > prereq and take it out of 'build_requires'.
That seems like a good idea. -- David
Subject: M::B::Compat can create duplicates in PREREQ_PM
Date: Thu, 29 Oct 2009 10:49:22 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
BinGOs reports cases where PREREQ_PM contains duplicates with different version numbers. This is probably an issue in how PREREQ_PM merges requires and build_requires.
Patched in trunk