Bug 198027 - false RPM Requires "perl(the)"
Summary: false RPM Requires "perl(the)"
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-Image-ExifTool
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
: 198538 198588 (view as bug list)
Depends On: 198033
TreeView+ depends on / blocked
Reported: 2006-07-08 06:35 UTC by J. Randall Owens
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-07-11 13:58:34 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 198033 0 medium CLOSED [patch]: tweak perl.req to cut down false Requires 2021-02-22 00:41:40 UTC

Internal Links: 198033

Description J. Randall Owens 2006-07-08 06:35:15 UTC
Description of problem:
When attempting to install the new release from
I get
> # rpm -Uhv ../noarch/perl-Image-ExifTool-6.26-1.fc5.noarch.rpm
> error: Failed dependencies:
>         perl(the) is needed by perl-Image-ExifTool-6.26-1.fc5.noarch
> Exit 1

Of course, this can be overcome with --nodeps, but then smart et al. always want
to helpfully uninstall it for you, and you can't install it through them in the
first place.

Version-Release number of selected component (if applicable):

How reproducible:
Attempt to install the noarch package.

Steps to Reproduce:
1. Download perl-Image-ExifTool-6.26-1.fc5.noarch.rpm
2. rpm -Uhv perl-Image-ExifTool-6.26-1.fc5.noarch.rpm
3. try to find a package that provides perl(the)
Actual results:
package does not install without --nodeps

Expected results:
package installs cleanly

Additional info:
Since I came across this while learning the joys of spec files and rpmbuild, and
knowing perl already, I grabbed the SRPM and poked around in it. I found that
/usr/lib/rpm/perl.req generates a "perl(the)" requirement in

> BUILD/Image-ExifTool-6.26/lib/Image/ExifTool                                 
                                         > $ /usr/lib/rpm/perl.req MIE.pm
> perl(Image::ExifTool)
> perl(Image::ExifTool::Exif)
> perl(Image::ExifTool::GPS)
> perl(strict)
> perl(the)
> perl(vars)

I dug around in the source code, and I'm pretty sure it's because perl.req
falsely finds a requirement in line 148 which is actually quoted:

143-        Notes => q{
144-            Currently defined types are ACR, AIFC, AIFF, ASF, AVI, BMP, CR2,
145-            DNG, EPS, ERF, GIF, ICC, JNG, JP2, JPEG, MIE, MIFF, MNG, MOS,
MOV, MP3, MP4,
146-            MPEG, MRW, NEF, ORF, PBM, PDF, PGM, PICT, PNG, PPM, PS, PSD,
147-            RIFF, SR2, SRF, TIFF, WAV, WMA, WMV, X3F and XMP.  Other types
should simply
148:            use the common file extension.
149-        },

it just sees "use the" at the beginning of the line, and tallies up a requirement.

A possible workaround could be a patch to paraphrase that by moving "types" onto
the next line in front of "use". An ideal fix would be to improve the perl.req
parsing. A pretty good fix would be if there's a way to specify in the spec file
that a requirement should be excluded, but if there's a tag for that, I haven't
gotten that far into the spec file information yet.

There might be more files with more "use the" or even "require the", but I've
run perl.req on everything in BUILD/Image-ExifTool-6.26/lib/ and that's the only
one that came up, and while I don't understand the perl make process well yet, I
think everything in blib/ would be either a copy or source of the stuff in lib/?
Other than that, exiftool itself is clean, and I wouldn't think it would be in t
/ or html/.

Comment 1 J. Randall Owens 2006-07-08 06:44:10 UTC
Afterthought: I've found quite a few similar odd Requires in perl packages in
the past that prevented me from installing or upgrading them easily. Since I do
know perl, and noticed that /usr/lib/rpm/perl.req is in perl itself, perhaps the
best thing to do would be submit a bug for rpm-build and see if I can figure out
a way to parse those quotes out, preferably without bogging things down n
examining the entire context too much. I'll take a look at SRPMs for those other
packages and see what I come up with. If I do submit a bug for rpm-build, I
might set that as a "depends on" (if a common user can set depends/blocks on
bugzilla, I don't know yet).

Comment 2 J. Randall Owens 2006-07-08 12:23:26 UTC
Created bug 198033 ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198033
) against rpm package (source RPM of rpm-build, the real culprit). Added as
blocking this one, though either one could be fixed in various ways before the

Comment 3 Victor Bogado 2006-07-11 00:17:12 UTC
The main problem with this is that this "disables" the automatic update of the
"yum" service and could potentially block a user from updating a security update. 

But this is another bug also... ;-)

Comment 4 Tom "spot" Callaway 2006-07-11 13:58:34 UTC
Resolved in 6.26-2. Real bug is in 198033 though.

Comment 5 Tom "spot" Callaway 2006-07-11 18:21:39 UTC
*** Bug 198538 has been marked as a duplicate of this bug. ***

Comment 6 Tom "spot" Callaway 2006-07-12 05:24:19 UTC
*** Bug 198588 has been marked as a duplicate of this bug. ***

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