Red Hat Bugzilla – Bug 59159
Autogenerated perl dependencies: you are now entering a world of pain
Last modified: 2008-05-01 11:38:01 EDT
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
[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.
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.