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): rpm-build-4.0.4-7x How Reproducible: 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 Actual Results: requires only .so's, perl, sh but no .pm Expected Results: .so's, sh, perl, perl(...) Additional Information: 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. Do 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.