From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705) Description of problem: find-requires seems to be digging through %doc files looking for package requirements, which it really shouldn't! Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. put a perl script in a %doc for a package that doesn't require perl at all 2. rpmbuild -ba snafu.spec 3. rpm -i snafu-*.i386.rpm Actual Results: hypothetical binary rpm file will fail to load if the perl rpms aren't installed! (especially when the hypothetical binaries in the rpm don't depend on perl one whit!!) Expected Results: the binary rpm file should load. after all, the hypothetical binaries themselves don't depend on perl, and package authors shouldn't be forced to limit package documentation to files that find-requires shouldn't be "discovering" in the first place! Additional info:
Dependencies are generated only if the execute bit is set. Turn off the execute bit, dependencies won't be generated.
"NOTABUG"?!? Excuse me? Please explain, in Red Hat's estimable opinion, how a sample perl script with the execute bit set and listed as %doc has any bearing on a *real* package dependency! Better yet, provide *one* real-world example!! It would seem obvious, once one thinks about it for even a moment, that if the package *really* required it to function, then it would be in a %file and not a %doc. Who cares what the permissions are on a documentation file? If a %doc file is an example shell script, you bet I'm going to set the execute bit so that color ls can give me a visual clue. Yes, even an execute bit can serve as documentation, imagine that!! I even looked in the maximum rpm docs on disc 6 to see if this "new" behavior was even documented; and if it is, I couldn't find it! This *new* "undocumented feature" in rpm 4.1 is one that seems ill conceived... One should continue to be allowed to use file permissions as documentation and not have to worry about find-requires finding out and thinking it's some kind of *real* package dependency!!
It's NOTABUG because it's a package, not rpm, error. The described fix is the behavior for all versions of rpm, not rpm-4.1, the behavior has not changed in a Very Long Time. The only new behavior is autogenerating perl dependencies, which can be disabled (re-establishng the previous behavior of rpm) by doing chmod -x /usr/lib/rpm/perl.{prov,req}
Ack! Are you actually grokking what I'm writing? Apparently not... so I'll summarize for you. 1. having find-requires finding perl dependencies is *GOOD* (been a long time coming)! 2. having find-requires searching %doc for package dependencies is *BAD*! Now to address your quite terse responses: 1. A bug that's been around for a long time is *still* a bug and not a "feature by tenure". 2. The "new" behavior of find-requires (finding perl dependencies) for package %files (the package "proper") isn't the problem... the problem is find-requires thinking that actual package dependencies should be discovered in package %docs (the package documentation)!! find-requires says "# --- Grab the file manifest and classify files." Obviously, it's mis-classifying perl scripts in documentation as part of the functional package when it's very obviously classified in the spec file as *DOCUMENTATION*. It *IS* a bug. Now, if Red Hat simply won't fix it, then close it as "WONTFIX" and not as "NOTABUG"! At least that will serve to actually document this (undesirable) behavior SOMEWHERE!!