https://bugzilla.redhat.com/show_bug.cgi?id=2126943 --- Comment #9 from Petr Pisar <ppisar@xxxxxxxxxx> --- (In reply to Damian Wrobel from comment #5) > For the reverse direction I'm getting: > > [dw@dell Plugin]$ scandeps.pl -V -B -R CGI.pm > # Template/Plugin.pm [module] > # Template/Plugin/CGI.pm [module] > # base.pm [module] > # strict.pm [module] > # warnings.pm [module] > # > # Legend: [C]ore [X]ternal [S]ubmodule [?]NotOnCPAN > 'Template::Plugin' => '0', # ? # Template::Plugin::CGI > 'base' => '0', # C? # Template::Plugin::CGI > 'strict' => '0', # C? # Template::Plugin::CGI > 'warnings' => '0', # C? # Template::Plugin::CGI > Yet if you look at CGI.pm, line 26: 19 package Template::Plugin::CGI; 20 our $AUTHORITY = 'cpan:TODDR'; 21 # ABSTRACT: Simple Template Toolkit plugin interfacing to the CGI.pm module 22 $Template::Plugin::CGI::VERSION = '3.101'; 23 use strict; 24 use warnings; 25 use base 'Template::Plugin'; → 26 use CGI; There is a clear use of CGI module. And the tool misses it. I don't know why. On my system it at least discovers it and than hides it. That's why I wrote that the tool probably has bugs. > While cpanspec gives me: > > [dw@dell cpan]$ cpanspec Template-Plugin-CGI-3.101.tar.gz > [dw@dell cpan]$ grep '^BuildRequires:' perl-Template-Plugin-CGI.spec > BuildRequires: perl(CGI) >= 4.44 > BuildRequires: perl(ExtUtils::MakeMaker) > BuildRequires: perl(File::Spec) > BuildRequires: perl(File::Temp) > BuildRequires: perl(IO::Handle) > BuildRequires: perl(IPC::Open3) > BuildRequires: perl(Template) >= 3.100 > BuildRequires: perl(Test2::Bundle::Extended) > BuildRequires: perl(Test2::Plugin::NoWarnings) > BuildRequires: perl(Test2::Suite) > BuildRequires: perl(Test2::Tools::Explain) > BuildRequires: perl(Test::Builder) > BuildRequires: perl(Test::CPAN::Meta) > BuildRequires: perl(Test::More) > Because cpanspec does not read the Perl source code at all. It only looks into META.yaml (and maybe META.json) and spits out what's written there. > Is there any authoritative method of automatically retriving list of BRs for > a perl module a I could use? It isn't. That's an inherent property of all Turing machine-complete programming languages. You can only have tools which provide approximate results and then you need a packager who use a common sense and experience to judge the results. The dynamic analysis scandeps does is actually pretty good, but to use is seriously, one would need to instrument it more and apply on different pieces of code (e.g. "perl Makefile.PL" and "make test"). In the past I started developing a tool like that but I stopped for two reasons: First perl interpreter's introspection facilities for loading modules is buggy and differs from a perl version to version. It was impossible to make it reliable and portable. Second reason was that at some level the introspection itself influences perl interpreter and the analyzed code. It resulted into a garbage output, or the analyzed code diverted from it's original code path, or the analysis hit Perl's recursion limit and crashed or never halted. My recommended way is reading metadata provided by upstream (META.json, META.yaml, or Makefile.PL, or dist.ini). Then doing a static analysis with tangerine tool. But you cannot blindly trust them. If it is feasible, it's good to verify a usage of the declared/discovered dependencies by grepping, and reading the source code. Also rewriting the module identifier in the source code and then verifying that Makefile.PL && make test fails is sometimes necessary. Also optional dependencies, especially in tests can be tricky. Sometimes they do not do anything helpful (like pretty-formatting a debugging output, or reporting module versions, or criticizing a code style) and it's better to omit them. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2126943 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
