Skip Menu |

This queue is for tickets about the Filter-Crypto CPAN distribution.

Report information
The Basics
Id: 50107
Status: resolved
Priority: 0/
Queue: Filter-Crypto

People
Owner: Nobody in particular
Requestors: ANDK [...] cpan.org
Cc:
AdminCc:

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



Subject: Undeclared dependency on Pod::Usage
Paging through the cpantesters results there are several candidates that might explain the FAILs. I'll step forward with the most obvious, that's the dependency on Pod::Usage that isn't declared in the Makefile.PL. I expect other reasons can be identified more easily once this dependency declaration is added. Thanks && Regards,
Thanks for looking at this, but I don't believe this is the cause of the CPAN Testers FAILs because the Makefile.PL (and all the other perl source files in the distribution) contains "use 5.006000", and perl-5.6.0 contains Pod::Usage. I therefore deliberately didn't declare it, just like I didn't declare any other modules that were in the perl core since 5.6.0.
I've now tried running the tests using the minimum version of perl supported by Filter-Crypto, namely 5.6.0, which contains Pod::Usage 1.12, and all the tests (including the final 03_script.t test regarding the Pod::Usage) pass. (I had to hack my perl-5.6.0 slightly because the tests require Test::More, which wants ExtUtils::MakeMaker >= 6.27, which wants Win32, which wants four symbols that 5.6.0's DLL didn't export, but that's got nothing to do with this ;-) Therefore, I'm closing this ticket since it can't be the cause of the CPAN Testers FAILs (unless they've been vandalizing their perl installations to not include Pod::Usage, which seems unlikely).
You seem to imply that those who ran the tests are the ones who vandalized their perl. This is not very helpful to the user who probably unknowingly has to work with a vandalized perl. Is it easier to declare a dependency when you encounter fails due to a missing one or to declare it their fault? Shortsighted the latter seems easier but if you really want to find out remaining interesting bugreports then it helps tremendously to fix trivial things first. Besides that it is always possible that some day some perl will come without Pod::Usage. So why not prepare for the day now?
Okay, you might have persuaded me of the merits of declaring all modules used (even core ones)... However, I still feel it won't fix bug reports like these: http://www.nntp.perl.org/group/perl.cpan.testers/2009/09/msg5447753.html http://www.nntp.perl.org/group/perl.cpan.testers/2009/09/msg5289494.html I just tried again with a vandalized perl having no Pod::Usage in it, and you can't even build Filter-Crypto because it is used in the Makefile.PL: C:\Dev\Build\Filter-Crypto-1.25>perl Makefile.PL Can't locate Pod/Usage.pm in @INC (@INC contains: inc C:/perl560/lib C:/perl560/site/lib .) at inc/Module/Install/PRIVATE.pm line 31. BEGIN failed--compilation aborted at inc/Module/Install/PRIVATE.pm line 31. Compilation failed in require at inc/Module/Install.pm line 261. Can't call method "process_opts" without a package or object reference at Makefile.PL line 82. And even if you build Filter-Crypto with Pod::Usage in place, then get rid of it before running the tests (which surely no CPAN Testers will be doing), the pattern of test failures is completely different to either of those reports: t/03_script.t (Wstat: 512 Tests: 71 Failed: 51) Failed tests: 1, 3-4, 7-9, 11-13, 15-17, 19-21, 23-26 28-42, 44-47, 49-52, 54, 57-58, 60-61, 63 66-67, 71 Non-zero exit status: 2 Parse errors: Bad plan. You planned 99 tests but ran 71. Files=6, Tests=369, 30 wallclock secs ( 0.33 usr + 0.02 sys = 0.34 CPU) Result: FAIL
That's what configure_requires has been invented for. The principle of configure_requires is that the META.yml has the information and both CPAN{,PLUS}.pm read it from there and then make the requirement available before the {Makefile,Build}.PL is being executed. Thank you for persuing this further.
The Pod::Usage dependency, and all other core module dependencies that I had previously (intentionally) not declared, is now declared in 1.25, just uploaded to CPAN. Thanks for the report (and your persistence).
As I predicted, adding the declaration of Pod::Usage didn't fix the failures in that area, e.g.: http://www.nntp.perl.org/group/perl.cpan.testers/2009/10/msg5550336.html http://www.nntp.perl.org/group/perl.cpan.testers/2009/10/msg5579882.html :-(
Not sure why CPAN RT re-opened the ticket when I specifically asked it to leave it "resolved (Unchanged)"...