Bug 234691 - Adds dependencies for %doc files
Adds dependencies for %doc files
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
12
All Linux
high Severity high
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
: 463461 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-31 07:05 EDT by Enrico Scholz
Modified: 2010-12-05 02:16 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 02:16:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2007-03-31 07:05:46 EDT
Description of problem:

rpm generates dependencies for files which are marked as %doc. Since packages
must work without such files (e.g. when installed with '--excludedocs'), such
dependencies are unneeded.

Often, there are sample scripts marked as %doc, which are adding bloaty deps on
perl. 

Therefore, rpm must ignore %doc files when generating autodeps/-provides.


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

rpm-4.4.2-32
Comment 1 Jeff Johnson 2007-03-31 07:41:40 EDT
rpm adds dependecnies for files marked with an executable bit.

Since when do %doc files need execute permission?
Comment 2 Enrico Scholz 2007-03-31 08:49:22 EDT
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
Comment 3 Jeff Johnson 2007-03-31 17:58:47 EDT
Ah, that's a different matter. Thanks for the reproducer. Fix in a few ...

Comment 4 Jeff Johnson 2007-03-31 18:16:07 EDT
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.



Comment 5 Jeff Johnson 2007-03-31 18:21:00 EDT
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))
Comment 6 Jeff Johnson 2007-03-31 19:18:32 EDT
copyright jbj

UPSTREAM
Comment 7 Michael Jennings (KainX) 2007-04-03 12:55:45 EDT
Would it not be better to exclude any path with /doc/ in it?  Or is that too
far-reaching?
Comment 8 Jeff Johnson 2007-04-03 19:02:48 EDT
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.
Comment 9 Michael Jennings (KainX) 2007-04-04 12:27:08 EDT
(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.
Comment 10 Jeff Johnson 2007-04-04 19:14:56 EDT
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.
Comment 11 Red Hat Bugzilla 2007-08-21 01:32:52 EDT
User pnasrat@redhat.com's account has been closed
Comment 12 Panu Matilainen 2007-08-22 02:34:03 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 13 Bug Zapper 2008-05-13 22:43:04 EDT
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
Comment 14 Panu Matilainen 2008-09-27 07:55:00 EDT
*** Bug 463461 has been marked as a duplicate of this bug. ***
Comment 15 Bug Zapper 2009-06-09 18:31:33 EDT
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
Comment 16 Bug Zapper 2009-11-16 02:55:09 EST
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
Comment 17 Bug Zapper 2010-11-04 08:11:28 EDT
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
Comment 18 Bug Zapper 2010-12-05 02:16:32 EST
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.

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