Red Hat Bugzilla – Bug 65068
bug in rpm-build?
Last modified: 2008-05-01 11:38:02 EDT
Description of Problem:
In default installation of RH 7.2 with latest rpm-build from erratas script
/usr/lib/rpm/perl.req doesn't have execution permissions, and in
/usr/lib/rpm/find-requires condition '[ -x /usr/lib/rpm/perl.req -a -n
"$perllist" ]' doesn't allow to make auto-dependencies for perl modules.
Version-Release number of selected component (if applicable):
build any perl-module from spec-file without explicit specification of
libraries on which it relies.
Steps to Reproduce:
1. grab any src.rpm like perl-DBD-Mysql
2. remove hard-linked requirements to libraries
3. rpm -ba specfile
requires only .so's, perl, sh but no .pm
.so's, sh, perl, perl(...)
as soon as /usr/lib/rpm/perl.req gets +x everything is back to normal.
This is a (ahem) requested "feature", not a bug, for
Red Hat 7x.
chmod +x /usr/lib/rpm/perl.req
if you want auto-generated perl dependencies.
But isn't that easier to make at least additional flag for
/usr/lib/rpm/find-requires to activate perl.req on purpose? Because now, if I
want perl requirements to generate automaticly I should chmod +x perl.req and
if I don't want to - I should chmod -x perl.req. I there was a flag like
--check-perl or something it would be easier to make custom .spec files. By
the way - with current model most of rpm's are built without proper
dependencies :( and it's an implied problem from what I describe.
Or, maybe, it's a good question for rpm.org?
The right thing to do is to turn on auto-generation
of perl Requires: IMHO, that leads to better packaging.
There is little need to have Yet Another Option because
chmod +/-x is at least as effecient as any other
mechanism for enabling/disabling perl dependencies.
For every package turn on and off in the build-time (depending on a
package)? Noncense. As far as I understand how src.rpm & rpm-build should
work is to be as much independent as possible - that means that if I use for
example a "bad" package with bad provides in "Requires" and option of
running perl autodependencies is on (chmod +x), than I'm in a big trouble on
some installations because rpm wouldn't find requested feature (e.q.
perl(URI)), and vice versa - if option is off by default then all "good"
packages which rely on perl autodependencies will have almost nothing in
"Requires" (this is my situation) and when I'll go with installation on my
server it finally turns out that this package should reuire couple of other
packages but it doesn't.
It took me half of day to find out why autodependencies don't work only in
case of perl. And, by the way not all packages provide valid information
about themselves. Some of them (perl-Digest-MD5, perl-URI and others) don't
provide "Provides" in style perl(Digest::MD5), perl(URI) and sometimes it's
better (but not good) to turn off autogeneration for perl modules, but it's
better to be "on" by default IMHO.
We agree that auto-geberated perl dependencies
should be "on" by default. 'Twasn't my call,
and I lost the argument. <shrug>
so would you fix that or it is gonna be "requested feature"? :)
The perl dependencies are "on" by default
in rpm-4.1. That's the best I could do.
Yes it's weird having different versions
of rpm performing different actions. Again,
not my call.
Enabling a CLI switch (other than chmod +x)
just leads to a mess IMHO.