Bug 234691

rpm adds dependecnies for files marked with an executable bit.

Since when do %doc files need execute permission?

Name:		foo1
Version:	1
Release:	1
Summary:	none
Group:		none
License:	GPL
BuildRoot:	%_tmppath/%name-%version-%release-root

%description

%prep
%setup -c -T

cat <<EOF >> foo.pm
package foo;
use strict;
EOF

chmod -x foo.pm

%files
%defattr(-,root,root,-)
%doc foo.pm

====

| $ rpm -qp --filerequire -lv  /var/tmp/sessiondir-ensc.1175237838.yX5046/redhat/RPMS/i386/foo1-1-1.i386.rpm
| /usr/share/doc/foo1-1
| /usr/share/doc/foo1-1/foo.pm    perl(strict) 
| drwxr-xr-x    2 root    root                0 Mar 31 14:47 /usr/share/doc/foo1-1
| -rw-r--r--    1 root    root               25 Mar 31 14:47 /usr/share/doc/foo1-1/foo.pm


==> There are no executable files in the package but a perl dep was
    created for the %doc file

Ah, that's a different matter. Thanks for the reproducer. Fix in a few ...

The problem is that perl is too irregular for libmagic classification.

Perl dependency closure problems forced ".pm" suffix content classification:
            /* XXX all files with extension ".pm" are perl modules for now. */
            if (_suffix(s, ".pm"))
                ftype = "Perl5 module source text";

Marking as RPMFC_MODULE
  { "Perl5 module source text", RPMFC_PERL|RPMFC_MODULE|RPMFC_INCLUDE },
causes perl requires to be generated
    if (fc->fcolor->vals[fc->ix] & RPMFC_PERL) {
        if (fc->fcolor->vals[fc->ix] & RPMFC_MODULE)
            xx = rpmfcHelper(fc, 'P', "perl");
        if (is_executable || (fc->fcolor->vals[fc->ix] & RPMFC_MODULE)) 
            xx = rpmfcHelper(fc, 'R', "perl");
    } else

Hmmm ... hacky fix but I can't think of better w/o better disciplined package monkeys:
Index: lib/rpmfc.c
===============================================================
====
RCS file: /cvs/devel/rpm/lib/Attic/rpmfc.c,v
retrieving revision 1.1.2.7
diff -u -b -B -w -p -r1.1.2.7 rpmfc.c
--- lib/rpmfc.c 13 Feb 2007 16:03:10 -0000      1.1.2.7
+++ lib/rpmfc.c 31 Mar 2007 22:14:04 -0000
@@ -738,10 +738,12 @@ static int rpmfcSCRIPT(rpmfc fc)
     (void) fclose(fp);
 
     if (fc->fcolor->vals[fc->ix] & RPMFC_PERL) {
+       if (!strncmp(fn, "/usr/lib", sizeof("/usr/lib")-1)) {
        if (fc->fcolor->vals[fc->ix] & RPMFC_MODULE)
            xx = rpmfcHelper(fc, 'P', "perl");
        if (is_executable || (fc->fcolor->vals[fc->ix] & RPMFC_MODULE))
            xx = rpmfcHelper(fc, 'R', "perl");
+       }
     } else
     if (fc->fcolor->vals[fc->ix] & RPMFC_PYTHON) {
        xx = rpmfcHelper(fc, 'P', "python");

Here's the verifier:
$ rpm -qp --requires foo1-1-1.i386.rpm 
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1


In rpm cvs, will be in rpm-4.4.9-0.3 when built.

Hmm avoiding /usr/share/doc is likley less intrusive on non-linux, patch changed to
Index: lib/rpmfc.c
===============================================================
====
RCS file: /cvs/devel/rpm/lib/Attic/rpmfc.c,v
retrieving revision 1.1.2.8
diff -u -b -B -w -p -r1.1.2.8 rpmfc.c
--- lib/rpmfc.c 31 Mar 2007 22:17:49 -0000      1.1.2.8
+++ lib/rpmfc.c 31 Mar 2007 22:20:38 -0000
@@ -738,7 +738,7 @@ static int rpmfcSCRIPT(rpmfc fc)
     (void) fclose(fp);
 
     if (fc->fcolor->vals[fc->ix] & RPMFC_PERL) {
-       if (!strncmp(fn, "/usr/lib", sizeof("/usr/lib")-1)) {
+       if (strncmp(fn, "/usr/share/doc/", sizeof("/usr/share/doc/")-1)) {
            if (fc->fcolor->vals[fc->ix] & RPMFC_MODULE)
                xx = rpmfcHelper(fc, 'P', "perl");
            if (is_executable || (fc->fcolor->vals[fc->ix] & RPMFC_MODULE))

copyright jbj

UPSTREAM

Would it not be better to exclude any path with /doc/ in it?  Or is that too
far-reaching?

Classifying content based on path and/or suffix is intrinsically b0rken.

The bestest fix is do autocorrelation on tokens within perl module files. The
heuristics implemented in file(1) (and libmagic) are feeble an ~1993 hysterical.

See the stupid token table in rpm/file/src/names.h.

What's needed is a Bayesian classifier, like what is used to classify SPAM,
on the entire file content rather than a hand-crufted stoopid check on 1st token
encountered.

I've been meaning to hack a Bayesian classifier into file(1) for years, just not gotten there, sigh.

(In reply to comment #8)
> Classifying content based on path and/or suffix is intrinsically b0rken.

Granted.

> What's needed is a Bayesian classifier, like what is used to classify SPAM,
> on the entire file content rather than a hand-crufted stoopid check on 1st token
> encountered.

I'm not sure I understand how a Perl script in a documentation directory, for
which dependencies should *not* be generated, would be analyzed differently from
a Perl script in, say, a bin directory, for which dependencies *should* be
generated.

The issue for me is executable, not %doc nor /usr/share/doc.

Scripts that might be executed should have dependencies.

Scripts supplied as examples are fed to human eyes, not an interpreter. Remove the executable
bit in %doc, either by policy, or automatically, and the eyes will never know the difference.

Nor will invocations that explictll feed the script to an interpreter.

So dependencies should not be generated for non-executable files is the rule I wish to enforce in rpm, 
mostly because of hysterical continuity.

User pnasrat's account has been closed

Reassigning to owner after bugzilla made a mess, sorry about the noise...

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

*** Bug 463461 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.