Dear CPAN Testers,
I know you're trying to help, but if you can't configure your client to build any modules at all, your failure reports aren't telling me anything interesting that I can fix about my software.
If you really want my help getting this code to install, I'll send you my rate card in exchange for sudo access to your machine.
All the best,
chromatic
(See FAIL UNIVERSAL-can-1.12 x86_64-linux-gnu-thread-multi 2.6.8.1 and its two replies, as well as FAIL parrot-0.6.2 i686-linux 2.4.27-2-386.)
Call it not a bug, a tiny missing check, a minor lazyness of the parrot build gears, whatever. In any case it's pretty inappropriate to call perldoc without precautions and simply letting the first one in $PATH win. Something like
"${^X}doc
is quite a bit better, or using Pod::Simple directly with $^X. Such minor bugs in the build process can easily be spotted if you're so inclined to actually read reports from cpantesters.
Chromatic, no bonus points for this posting.
Re:At least the parrot fail report pretty obvious
chromatic on 2008-06-24T20:34:18
In any case it's pretty inappropriate to call perldoc without precautions and simply letting the first one in $PATH win.I agree, and that's a bug in our configuration process which I've just now fixed. (The configuration system already detected perldoc, but it didn't actually set the value appropriately.)
However, I can configure Parrot with Perl 5.10 and build it just fine without getting the
Devel::Autoflusherror from Perl 5.8.8. I don't even have that module installed on my system (and it's definitely not a requirement of Parrot.) That system has a problem unrelated to Parrot.Such minor bugs in the build process can easily be spotted if you're so inclined to actually read reports from cpantesters.I see no reason to trust reports from cpantesters with broken Perl installations.
