Description of Problem: Automatic generation of perl dependencies still needs tweaking a little ;o) There are odd constructions that can appear in perl scripts and modules that are still confusing the dependency-finding script(s). There are requirements for "POSIX(qw(isprint))" and "of" [sic] Version-Release number of selected component (if applicable): [bill@pikachu bill]$ rpm -q rpm-build perl-DBD-Pg gimp-perl rpm-build-4.0.4-0.23 perl-DBD-Pg-1.01-5 gimp-perl-1.2.1-8 Additional Information: [root@pikachu tmp]# rpm -Va --nofiles Unsatisfied dependencies for perl-DBD-Pg-1.01-5: perl(POSIX(qw(isprint))) Unsatisfied dependencies for gimp-perl-1.2.1-8: perl(Gimp::Util) , perl(of)
Yup, we're in the process of sanitizing perl Requires: ATM, gonna be another week or two before the dust clears. Try doing chmod -x /usr/lib/rpm/perl.req and do without autogenerated perl Requires: in rpm for a bit.
I'm not too worried about building them myself, I tend to be rebuilding GNOME packages to get around problems with libpng versioning (and I will use --nodeps for install/upgrade when I'm sure it's safe); I thought reporting these as I found them might help the process on a little. My take on these particular two problems was that they represent an interesting challenge (I've been ignoring the ones that were obviously "this package hasn't been rebuilt with the new perl requires handling yet :o) A suggestion if I might be so bold: something like an option in the .spec files to suppress individual items from the output of autoreqprov (and a corresponding global option in rpmmacros or rpmrc to handles e.g. things like "libsafe" which should not generally appear as a requirement even though they show up in ldd output). That way you could update a spec file to exclude bogons like the POSIX(qw(...)) example above. Otherwise the automatic generator would basically need to handle every possible combination of perl "features" like that one. But you've already thought ahead down that road I suspect.
Nod, all correct. FWIW, you can filter dependencies by writing a wrapper for /usr/lib/rpm/find-requires, to do essentially /usr/lib/rpm/find-requires | sed -e "s/perl(BOGUS)//" Put the name of the wrapper in a SourceN: directive, and tell rpm to use your wrapper with the macro %define __find_requires %SOURCEn (when n == N will need to be adjusted to taste) A bit clunky, but gets the job done.
That's quite a neat solution (aka I wish I'd thought of it :o) Any chance of formalising that a little (a NoDepend: tag or something, or a "standard" %define macro name, just so it's consistent) and factoring it into the find-requires and/or find-requires.perl scripts? Obviously I don't care how it's implemented ... :o)
Way ahead of you, I'm just trying to figger whether to bet on red or black :-)
OK, any chance of Maximum RPM being updated to cover this stuff?
(and ... uh ... where did roulette come into it? or have I missed something blindingly obvious as usual?)
Yeah, yeah, "Maximum RPM" has nothing to say about macros. That will change some day, probably not soon. RPM development and maintenance is rather like spinning the wheel, I only get to place wagers, and relatively small ones at that, on the outcome these days.