Construct a Perl source containing: require v5.6; Requirements analysis results: [buildmeister@colo2 tmp]$ /usr/lib/rpm/perl.req /tmp/foo.pl perl(v5.6) [buildmeister@colo2 tmp]$ /usr/lib/rpm/perldeps.pl --requires /tmp/foo.pl perl >= 0:v5.6 (For lurkers, see "perldoc -f require" for more on version strings in require statements.) In /usr/lib/rpm/macros for rpm-4.3.1-0.3 (current for FC2) is: #%__perl_requires /usr/lib/rpm/perldeps.pl --requires %__perl_requires /usr/lib/rpm/perl.req I note in bug 106672 that Jeff Johnson promises perl.req to be replaced with perldeps.pl "soonish". Here's some more ammunition to do so. Meanwhile, is there any good reason for packagers not to reverse the commenting in the global macros file?
Configure rpm however you wish. Changing default behavior in rpm takes forever these days ...
Here is a general question concring perldeps.pl. The old perl.req actually picked up the versions of libraries such that provides were versioned, and it tried to generate versioned requires. perldeps.pl does not do this. Regardless of whether this is the default vehicle for generating perl deps (like Jeff said you can configure it however you want), would you or other lurkers prefer perldeps.pl to try to pick the provides and requires version information? Cheers...james
Watch out, perldeps.pl --provides fails to supply "perl(Package)" when building CPAN packages with RPM::Specfile 1.17. RPM is rpm-4.3.1-0.3. Dependent packages will then complain about the missing dependency.