On Wed, 2005-11-16 at 21:12 +0200, Ville Skyttä wrote: > On Wed, 2005-11-16 at 06:47 -0600, Rex Dieter wrote: > > Enrico Scholz wrote: > > > > >>Therefore, I suggest one of the following rules: > > > > >>(a) %doc files MUST not introduce new dependencies, or > > > ok, I wrote an 'rpmlint' check for this rule: > > > Example output: > > > | $ rpmlint openvpn-2.0.5-1.fc4.i386.rpm > > > | E: openvpn %doc file '/usr/share/doc/openvpn-2.0.5/sample-scripts/auth-pam.pl' creates additional dependency '/usr/bin/perl' > > > | E: openvpn %doc file '/usr/share/doc/openvpn-2.0.5/sample-scripts/verify-cn' creates additional dependency '/usr/bin/perl' > > > > Excellent work and suggestion. I agree with your proposed addition to > > rpmlint. > > Me too, thanks, and will do. However, if included as is, I'm inclined > to make the message a warning instead of an error and soften the > phrasing a bit because of two things: > > The check doesn't do recursive depsolving (nor do I think it should), > ie. it will generate noise about things pulled in by other dependencies. > While strictly speaking this is not noise but the real thing, in > practice packagers rely on deps pulling in things even if the software > _directly_ requires something itself (not at all limited to doc files), > so this would be seen as noise by many folks. I don't have that strong > opinions on this though, we're talking about a lint tool anyway. > > The other thing is that the check strips versions from dependencies > altogether, while in a perfect world it should evaluate them against > other dependencies in the package and see if it is really a new one (for > example, let's say a Perl script in /usr/bin results in a perl >= > 0:500503 dependency, but a %doc file adds a perl >= 1:5.6.1 one -> no > message emitted, but should be). > > Thoughts? Enrico, did you send this upstream already? Another idea: how about making rpm simply make anything marked as %doc non-executable? That'd stop example scripts from accidentally pulling in dependencies for good... - Panu - -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
