Dependency hell: Bundle::CPAN, Pod::Coverage and Module::Build

[jkeenan1]

Nowadays, almost every time I use the cpan shell to install modules, I get prompted to upgrade to the latest version of Bundle::CPAN. I'm told that it should be a "seamless upgrade during the current session."

It never is.

Today's problem deals more with the aftermath of using Bundle::CPAN. While Bundle::CPAN was going through its paces, I noticed that many tests were being skipped because I didn't have Test::Pod or Test::Pod::Coverage installed. Now, I don't have very much use for either of those modules, but, for the sake of fewer warning messages, I decided to install them. Test::Pod installed without problem.

Test::Pod::Coverage was a different story. It depended upon Pod::Coverage v0.17. So cpan tried to install that module. It immediately got this warning:

Warning: this distribution contains XS files, but Module::Build is not
+ configured with C_support at /usr/local/lib/perl5/site_perl/5.8.7/Mo
+dule/Build/Base.pm line 1125.
Checking prerequisites...
 - ERROR: Devel::Symdump is not installed

cpan handled the lack of Devel::Symdump by installing it in the normal manner. But it couldn't figure out what to do with the warning about Module::Build, which is particularly aggravating given that, just minutes before, cpan had installed the latest version of Module::Build as part of Bundle::CPAN's operation! Without that particular feature of Module::Build, Pod::Coverage failed its tests and Test::Pod::Coverage did so as well.

In the hope that I would be prompted for the C_support option, I next tried to reinstall Module::Build. I got this message:

cpan> install Module::Build
Module::Build is up to date.

So cpan was not about to permit me to reinstall Module::Build in such a way as to get the C_support option needed for Pod::Coverage.

(I should note that when, during Bundle::CPAN's operation, I came to the prompt about PGP, I consistently chose the default option: 'skip all this cryptographic stuff'. As the alternative was installing 20 modules, more dependency hell lurked in that direction.)

So my questions are:

1. Should I try to (re-)install Module::Build manually so as to be presented with the C_support option?

2. Have other people faced this problem with Bundle::CPAN?

3. Could Bundle::CPAN be patched so as to avoid this problem?

Thank you very much.

[diotalevi]

It sounds like you opted to not install ExtUtils::CBuilder when you first installed Module::Build. It uses that module to do its XS building. Also, you can do a force install Module::Build to get your CPAN shell to install something it thinks is already the highest version.

[jkeenan1]

Diotalevi:

Your diagnosis and prescription were both correct. Once I installed ExtUtils::CBuilder on the server, I was able to do a force install Module::Build and get everything to DWIM.

Thanks again.

[jkeenan1]

Not so. I've had v0.03 of ExtUtils::CBuilder installed ever since I first installed Perl (then, 5.8.4) on this laptop.

UPDATE: My mistake. I was confusing a problem on my laptop with one on my server. I do not have ExtUtils::CBuilder installed on the server (and I'm not sure why not). I'll install it and try again.

Thanks, Perrin Diotalevi.

[perrin]

Test::Pod and Test::Pod::Coverage are useful for developers but not for users who don't plan to modify the code of the tested modules. It's doing the right thing by skipping those tests, and you should let it.

[jkeenan1]

But I am a developer! Moreover, I've successfully installed both Pod::Coverage and Test::Pod::Coverage on my laptop (Mac). I'm encountering these problems on my Linux (Debian) server.

[cees]

If you are using Debian, you can solve a lot of those problems by installing those support modules from the deb repository. Debian packages up a huge amount of perl modules, including the ones that you were having problems with.

• libmodule-build-perl
• libtest-pod-coverage-perl
• libtest-pod-perl

Now these packaged version may not be the absolute latest on CPAN, but since they are support modules and will not be used in your application, that should usually not concern you.

There is also an extra deb repo that contains more recent CPAN modules. Just add the following to your /etc/apt/sources.list config file:

deb http://debian.pkgs.cpan.org/debian unstable main

Although I don't know how up to date those are, since I haven't seen any changes to it recently....

[thor]

But I am a developer!

I think what he meant is that you're not a developer of the specific modules that are "complaining" about not having those modules installed. If you ever become a maintainer or contributer to a module that uses one of these modules in their testing framework, then you probably wouldn't ignore their lack of installation. However, not testing POD coverage for modules that you're installing doesn't affect their functionality, so it's safe to ignore those tests.