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
*** Bug 511931 has been marked as a duplicate of this bug. ***
*** Bug 517875 has been marked as a duplicate of this bug. ***
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.