Bug 521624 - RFE: please do not omit some checks for different input types
RFE: please do not omit some checks for different input types
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
: 511931 517875 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-07 06:25 EDT by Karel Volný
Modified: 2009-09-07 13:17 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-07 13:17:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2009-09-07 06:25:38 EDT
Description of problem:
When testing srpm, more specfile checks are run than when supplying just the specfile. For example the line lenght check, see the bug #517875.

This is mentioned in the documentation:

"All checks do not apply to all argument types.  For best check coverage, run rpmlint on source rpms instead of  plain  specfiles,  and installed binary rpms instead of uninstalled binary rpm files."


However, this behaviour seems to me irrational - if, for example, the line lenght can be checked while testing srpm and binary rpm, why it can't be tested with the plaintext .spec input?

Another example is the incoherent-version-in-changelog check mentioned within the bug #511931.

This can be annoying when creating large packages - re-running rpmbuild because of some formatting problem in .spec that wasn't revealed until srpm is tested, just to wait minutes before the data is copied, can be a PITA.

The same may go for installed/uninstalled binary packages, but I'm not aware of any test that differs.

Version-Release number of selected component (if applicable):
rpmlint-0.90-1.fc11.noarch

How reproducible:
always

Steps to Reproduce:
see the bugs #511931 or #517875
Comment 1 Karel Volný 2009-09-07 06:27:56 EDT
*** Bug 511931 has been marked as a duplicate of this bug. ***
Comment 2 Karel Volný 2009-09-07 06:45:07 EDT
*** Bug 517875 has been marked as a duplicate of this bug. ***
Comment 3 Ville Skyttä 2009-09-07 13:17:03 EDT
There are some reasons for the current behavior.

First, rpmlint does not have a full featured specfile parser, and almost certainly likely never will (although some improvements in this area may appear as/if functionality becomes available in python rpm bindings).  On the other hand, from binary and source packages we can get bits of information much more robustly, avoiding macro expansion/evaluation issues etc etc.  Therefore we're geared towards checking packages rather than specfiles.

Second, we want to avoid parroting same errors.  For example, if one runs rpmlint on a srpm and its corresponding binary rpm, we don't want to report same line length "problems" once for the specfile inside the source rpm, once for the source rpm, and once for each binary rpm produced.  I think we in some cases (maybe even this example one, didn't double check) fail to do this and there are duplicate issues reported, but I hope you get the point.

Third, some checks just do not make sense in all cases.  For example undefined symbol and unused direct dependency checks for ELF binaries require that the dependencies of the package being checked are installed, and the only scenario where we have any kind of assurance about this is when we're working on _installed_ binary packages.

Unfortunately I don't think this bug is fixable as is - all things just cannot be done for all types of checks, so I'm closing it as CANTFIX.  There certainly are areas where there is room for improvement, but those need to be handled as specific cases - there's no magic bullet that would fix everything in one go.  Feel free to report them as you come across them, preferably in the upstream tracker at rpmlint.zarb.org in case the issue is not specific to Fedora rpmlint packaging or guidelines.

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