This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Those deps are in fact generated automatically by perl-generators, based on this in the sources:

sqlninja-0.2.999-alpha1/sqlninja:
40:require "/usr/share/sqlninja/utils.pl";
41:require "/usr/share/sqlninja/session.pl";
42:require "/usr/share/sqlninja/fingerprint.pl";
43:require "/usr/share/sqlninja/bruteforce.pl";
44:require "/usr/share/sqlninja/escalation.pl";
45:require "/usr/share/sqlninja/upload.pl";
46:require "/usr/share/sqlninja/dirshell.pl";
47:require "/usr/share/sqlninja/revshell.pl";
48:require "/usr/share/sqlninja/backscan.pl";
49:require "/usr/share/sqlninja/dns.pl";
50:require "/usr/share/sqlninja/icmp.pl";
51:require "/usr/share/sqlninja/metasploit.pl";
52:require "/usr/share/sqlninja/test.pl";
53:require "/usr/share/sqlninja/sqlcmd.pl";
54:require "/usr/share/sqlninja/resurrectxp.pl";
55:require "/usr/share/sqlninja/getdata.pl";

(In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> Those deps are in fact generated automatically by perl-generators, based on
> this in the sources:
> 
> sqlninja-0.2.999-alpha1/sqlninja:
> 40:require "/usr/share/sqlninja/utils.pl";
[...etc...]

Yes, but those are paths WE'RE patching into the source. That's what the sqlninja-change-path-0.2.999-alpha1.patch file does.

The original paths are things like:

require "lib/utils.pl";
require "lib/session.pl";
require "lib/fingerprint.pl";

...because sqlninja as distributed isn't meant to be installed, it's meant to be run from the dist tree.

My Perl packaging is rusty, but it seems to me that instead of arbitrarily shoving the contents of lib/ into /usr/share/sqlninja/, those files should be installed to /usr/lib64/perl5/vendor_perl/SqlNinja/ instead. Then they can be loaded with statements like:

require "SqlNinja/utils.pl";
require "SqlNinja/session.pl";

and so on, correct? From my testing in `perlsh` it _seems_ as if that works, since the vendor_perl dir is in the default @INC. And I assume perl-generators won't pick out those paths as additional dependencies, since they're relative to vendor_perl.

Of course, it would be better if sqlninja distributed its components as actual Perl modules, properly installed into vendor_perl and loaded with "use SqlNinja::Utils;" and etc. But that'd require more rewriting, to turn the lib directory into an actual module package.

Actually, make that /usr/share/perl5/vendor_perl, aka %perl_vendorlib in /usr/lib/rpm/macros.d/macros.perl.

(In reply to "FeRD" (Frank Dana) from comment #6)
>
> My Perl packaging is rusty, but it seems to me that instead of arbitrarily
> shoving the contents of lib/ into /usr/share/sqlninja/, those files should
> be installed to /usr/lib64/perl5/vendor_perl/SqlNinja/ instead. Then they
> can be loaded with statements like:
> 
> require "SqlNinja/utils.pl";
> require "SqlNinja/session.pl";

So, that worked (using /usr/share/perl5/vendor_perl instead), as far as being able to run /usr/bin/sqlninja _itself_.

However, perl-generators was producing requires like:

perl(SqlNinja::utils.pl)

...but not producing the corresponding Provides. So, there were unsatisfied dependencies.

One solution to that is to simply REMOVE perl-generators from the BuildReq's entirely. (AFAICT it buys us nothing, with this package — all of the dependencies are missed, and have to be listed explicitly in the sqlninja.spec file anyway.) Then, the package installs and runs fine.

See the install-path branch in my fork, I'm hesitant to open a PR given the slightly-hackish nature of the changes.

https://src.fedoraproject.org/fork/ferdnyc/rpms/sqlninja/tree/install-path

I don't think they're hacky. The new spec file is cleaner than the previous version ;)
Please submit this as PR. Those file dependencies will most likely stop working in either 
F40 (https://discussion.fedoraproject.org/t/f40-change-proposal-dnfconditionalfilelists-system-wide/94939)
or F41 (https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5).

Done: https://src.fedoraproject.org/rpms/sqlninja/pull-request/1

The pull request was merged.