Skip Menu |

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

Report information
The Basics
Id: 66549
Status: open
Priority: 0/
Queue: Module-Build

Owner: Nobody in particular
Requestors: chad.a.davis [...]

Bug Information
Severity: Normal
Broken in:
  • 0.3603
  • 0.3800
Fixed in: (no value)

Subject: unshift vs push onto @INC
Assume I'm trying to install Dummy::Module from the CPAN shell, and Dummy::Module depends on Dummy::Prereq 0.02, and Dummy::Prereq 0.01 is available in $PERL5LIB (in a non-standard location, e.g. from local::lib). M::B makes a ./Build script that 'unshifts' all of the non-standard directories from $PERL5LIB onto the front of @INC. M::B notices the unsatisfied dependency. gets Dummy::Prereq 0.02 and tests it, but does not install it, because Dummy::Module has to be tested first. Instead, it prepends ./blib/lib and ./blib/arch to $PERL5LIB so that the updated versions will be found. It then tests Dummy::Module, using M::B. However the ./Build script then unshifts onto @INC any non-standard directories from $PERL5LIB that were present *before* Dummy::Prereq 0.02 was prepended to $PERL5LIB. I.e. if you install your modules to a non- standard location, you cannot install any (M::B) module for which you have an outdated prereq installed. I have been sending (many?) false alarms from CPAN::Reporter::Smoker because of this. It is not clear to me why @INC should be manipulated; @INC already contains $PERL5LIB, but assuming it should be manipulated, 'push' seems better. I changed this in the current git version, all tests still pass (patch attached). I was not clever enough to come up with a standalone test that would cause M::B to fail, but I have a contrived example attached. The sh script should not be executed directly (it contains an exec statement to create a pristine environment), but rather copy-pasted into a terminal. The session file shows the output that I see. You should be able to reproduce this, as long as your systems's perl install has a reasonably recent M::B. This issue happens to me on: 64 bit Perl 5.8.8 with MB 0.38 on CentOS 5.5 32 bit Perl 5.12.3 with MB 0.36 on Fedora 14 I also do not believe this depends on local::lib, as M::B finds any non- standard paths to prepend to @INC. I also believe that is behaving as it should, as it prepends $PERL5LIB so that the updated prereqs can be found.
application/octet-stream 2.7k

Message body not shown because it is not plain text.

Subject: module-build-script-session.txt

Message body is not shown because it is too large.

Subject: MB-INC.patch
Download MB-INC.patch
text/x-diff 355b
diff --git a/lib/Module/Build/ b/lib/Module/Build/ index 3ffca3b..384bec6 100644 --- a/lib/Module/Build/ +++ b/lib/Module/Build/ @@ -1847,7 +1847,7 @@ BEGIN { die ("Configuration seems to be out of date, please re-run 'perl Build.PL' again.\\n"); } } - unshift \@INC, + push \@INC, ( $quoted_INC );
From: chad.a.davis [...]
Download (untitled) / with headers
text/plain 167b
I would also hide ~/.cpan and ~/perl5 , if you have them, before trying the attached script. (Updated output of my script session after fixing minor bugs in script).
Subject: module-build-script-session.txt

Message body is not shown because it is too large.

Download (untitled) / with headers
text/plain 204b
This sounds suspiciously similar to the following bug in local::lib: Can you replicate this without using local::lib, but with a PERL5LIB set manually?
From: chad.a.davis [...]
Download (untitled) / with headers
text/plain 1.3k
Show quoted text
> Can you replicate this without using local::lib, but with a PERL5LIB
set Show quoted text
> manually? >
Yes. The symptoms are the same as with that local::lib issue, but I believe that the issue here is within M::B itself, as it saves components from $PERL5LIB and then unshifts them back onto $PERL5LIB from the ./Build script. These path components precede the components that CPAN prepends (./blib/lib and ./blib/auto) so that the outdated deps are found before the just-built updated deps. I simplified the demo script for this case. You should be able to run this if you simply start with a clean environment: exec -cl /bin/bash --noprofile and then wget -q and finally sh Comments in the script explain what's happening. Essentially, it gets an outdated prereq installed (to a custom lib path), then tries to install a module that requires a newer prereq. You need to have Module::Build and Test::More already installed (e.g. via your package manager). Tested on Fedora 14 + perl 5.12.3 + M::B 0.3603 CentOS 5.6 + perl 5.8.8 + M::B 0.2807 Ubuntu 11.04 + perl 5.10.1 + M::B 0.340201 Ubuntu 11.04 + perl 5.10.1 + M::B 0.38 The last two are AWS AMIs, to be sure that there were no custom quirks. In the latter case, I installed the latest M::B with the system cpan. None of the cases used local::lib.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to