Bug 595480 - rpmlint complains about "dangerous-command-in-%pre" in default gconf macros
rpmlint complains about "dangerous-command-in-%pre" in default gconf macros
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-24 14:38 EDT by Christian Krause
Modified: 2010-06-06 05:50 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-06 05:50:07 EDT
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 Christian Krause 2010-05-24 14:38:10 EDT
Description of problem:
When using the default GConf2 macros as suggested in the most recent packaging guidelines: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GConf
rpmlint complains about the usage of "rm" in %post/%pre:
W: dangerous-command-in-%pre rm
W: dangerous-command-in-%post rm


Version-Release number of selected component (if applicable):
rpmlint-0.95-2.fc13.noarch

How reproducible:
100%

Steps to Reproduce:
1. use macros %gconf_schema_prepare, %gconf_schema_upgrade in spec file
2. build package, run rpmlint
  
Actual results:
W: dangerous-command-in-%pre rm
W: dangerous-command-in-%post rm

Expected results:
In general the suggested scriptlets in the packaging guidelines should not trigger rpmlint warnings.
Comment 1 Ville Skyttä 2010-05-24 15:13:44 EDT
I'm inclined to close this as NOTABUG, because:

1) rm is indeed a dangerous command to be used in scriptlets, and often there is a better way to do stuff in scriptlets than using it.

2) rpmlint has no way of knowing where the rm came (expanded) from, it just sees it in binary packages so I don't think it can be selectively disabled just for this case.

3) It is just a warning, you're free to ignore the message (ditto all other rpmlint messages, no matter if they're errors or warnings) if you're certain you know better than rpmlint.

Will keep open for a while in case there are convincing arguments against the points above.
Comment 2 Christian Krause 2010-06-01 18:31:49 EDT
(In reply to comment #1)
> I'm inclined to close this as NOTABUG, because:

I would agree that this is not necessarily a problem of rpmlint. It may also be considered a problem of the rpm macros provided by the GConf2 package. However, in combination I'm convinced that there is a valid problem.

> 1) rm is indeed a dangerous command to be used in scriptlets, and often there
> is a better way to do stuff in scriptlets than using it.

Agreed, in this case it could be probably fixed in the GConf2 rpm macros.
 
> 2) rpmlint has no way of knowing where the rm came (expanded) from, it just
> sees it in binary packages so I don't think it can be selectively disabled just
> for this case.

Agreed.

> 3) It is just a warning, you're free to ignore the message (ditto all other
> rpmlint messages, no matter if they're errors or warnings) if you're certain
> you know better than rpmlint.

I disagree with this statement. ;-) In theory I think it should be possible to create packages conforming to the packaging guidelines which does not cause any rpmlint warnings.

The reasons are the following:

1. New packagers may be confused by "false positives". The reviewer (and the guidelines) requires a verification with rpmlint. There is no easy way (especially for new people) to easily distinguish between critical errors / warnings and warnings which can be ignored.

2. For all packagers it is getting harder and harder with all additional checks (like spell checking etc.) to find the real warnings within the growing number of lines of nonrelevant warnings.

3. The purpose of rpmlint is to help all packagers. If its reports contain two many "ignorable" warnings (e.g. using the desired GConf2 macros as suggested by the guidelines ;-) ), the people will get used to them and will finally ignore the rpmlint warnings.


So it would be OK to move the bug report to the GConf2 module, but I'm against closing it as NOTABUG. I'll leave it up to you. ;-)
Comment 3 Ville Skyttä 2010-06-06 05:50:07 EDT
(In reply to comment #2)
> I disagree with this statement. ;-) In theory I think it should be possible to
> create packages conforming to the packaging guidelines which does not cause
> any rpmlint warnings.

In theory, yes.  In practice however, Fedora Guidelines and rpmlint are not bound to each other, both of them will always have items that the other doesn't, and both evolve at their own pace, developed by different parties (that are however aware of each other).  Also, they do different things: Fedora Guidelines are more like "rules", whereas rpmlint as its name says is a "lint" tool that will by its nature flag more things.  There are however things that will work for both, and yes there are bugs in rpmlint and they get fixed all the time (such as the spell checking noise you mentioned which has been again reduced upstream post 0.97), but IMHO this isn't one of them.

Now, if someone wants to "castrate" rpmlint into something that will only check things in Fedora guidelines (ideally someone who's involved with maintaining those guidelines), I won't stand in the way and will help with making that possible (in case it already isn't for some reason) as long as it's done in a way that makes running the "full" rpmlint still possible as easily as it currently is.  But I don't personally plan to maintain such a rule set/config file.  See e.g. the discussion in bug 537430.

So, as far as rpmlint is concerned, I'm closing this as NOTABUG.  Feel free to reopen and assign to GConf2 if you think there's something that could/should be done about this in it.

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