On 2016-01-14 15:44:28, PERLANCAR wrote:
Show quoted text> From the fail reports for 1.61 (fails for 1.62 are not coming in yet),
> I see two remaining kinds:
>
> 1) "Died: Unknown arguments to new(): Filter, l4p_depends_on,
> l4p_post_config_subs, min_level, name at
> /usr/perl5.18.2/lib/site_perl/5.18.2/Log/Dispatch/FileWriteRotate.pm
> line 27."
>
> This is caused by an older version of Log::Dispatch::FileWriteRotate
> (< 0.03) which is a prereq for Log::Any::App, which is a prereq for
> Perinci::CmdLine::Classic.
>
> How do you propose resolving error reports like this? Should I release
> a new version of Log::Any::App just to bump the prereq version of
> Log::Dispatch::FileWriteRotate? Should I then also release a new
> version of Perinci::CmdLine::Classic just to bump the prereq version
> of Log::Any::App? For a large dependency tree, this could lead to
> loads of new minor releases.
In a perfect world, this would be the right solution.
Show quoted text> On the other hand, testers could test
> with a clean(er)/fresh(er) installation and purge old versions of
> modules.
This is not a good solution. Test machines should reflect the real world of real users. And there are different types of users: some who always install everything from scratch on an empty system; some who keep everything up-to-date; and some who only update or install modules if they have to, typically having a somewhat outdated system (the latter could be seen as a loosened "never touch a running system" approach). So a module author cannot assume the state of a user's installation to be completely up-to-date.
Show quoted text> 2) "Record #0 of streaming argument 'input' fails validation: Not of
> type decimal number at (eval 189) line 50, <> line 1." I haven't
> pinned the cause yet, probably has something to do with older versions
> of Data::Sah or other modules, but this is not listed in the reports
> because Data::Sah is an indirect prerequisite.
>
> I am thinking of adding a routine in the test scripts to print out the
> content of %INC and the installed versions of loaded modules listed
> there, to help debugging the problem. What do you think of that? Do
> you know if something like this is already supported?
Well, then you're maybe interested in
https://rt.cpan.org/Ticket/Display.html?id=109900
CPAN::Testers::ParseReport is used for creating the statistical reports at
http://analysis.cpantesters.org/ , so using Module::Versions::Report (or a compatible output) could help to find problematic dependencies automatically.
RT for rt.cpan.org