Bug 59159 - Autogenerated perl dependencies: you are now entering a world of pain
Summary: Autogenerated perl dependencies: you are now entering a world of pain
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm-build (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-01-31 22:37 UTC by Bill Crawford
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-31 22:37:48 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bill Crawford 2002-01-31 22:37:43 UTC
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

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)

Comment 1 Jeff Johnson 2002-01-31 22:56:05 UTC
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.

Comment 2 Bill Crawford 2002-01-31 23:22:25 UTC
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.

Comment 3 Jeff Johnson 2002-02-01 13:47:04 UTC
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.

Comment 4 Bill Crawford 2002-02-01 16:04:48 UTC
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)

Comment 5 Jeff Johnson 2002-02-01 16:19:15 UTC
Way ahead of you, I'm just trying to figger whether to bet on
red or black :-)

Comment 6 Bill Crawford 2002-02-01 17:08:43 UTC
OK, any chance of Maximum RPM being updated to cover this stuff?

Comment 7 Bill Crawford 2002-02-01 17:11:14 UTC
(and ... uh ... where did roulette come into it?  or have I missed something
blindingly obvious as usual?)

Comment 8 Jeff Johnson 2002-02-01 17:44:15 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.