rpmlint improvements - autoqa-devel - Fedora mailing-lists

17 Sep 2010


      Hello folks,
I want to discuss topics in tickets:
https://fedorahosted.org/autoqa/ticket/149
https://fedorahosted.org/autoqa/ticket/150
I did a test run of rpmlint against the latest RHEL6 tree and filed some bugs.
Some were legitimate but others turned out to be false negatives and developers
got angry.
Then it turned out that rpmlint needs more features in order to be used reliably
without making developers unhappy. So I talked to twoerner who is rpmlint
maintainer for RHEL6 and exchanged some ideas.
What we think is a good idea and needs to be present in upstream is having a
rpmlint-data package which will provide rules.$pkg-name files for packages that
need special handling. Then rpmlint will take into account those files and act
accordingly. The rules files will be maintained by a separate maintainer and not
by the packagers. Also any change into those rules/exceptions needs to be
approved with a review process to avoid pkg maintainers manipulating the rules
simply to silence out rpmlint output. This will guarantee accurate results.
This data package will be optional to rpmlint and not affect core functionality.
 It will most likely be different for Fedora and RHEL as well. This is more or
less the same as proposed in ticket 149 with lintian tool for Debian.
What do you think? Any drawbacks/gotchas you may think of?
The rules files format need to support the following (as identified so far):
* List file paths/directories with special permissions and uid/gid settings. For
example CUPS has such. audit also has such (in RHEL for certification purposes)
* Ignore some test cases for particular package(or file). For example:
gcc.x86_64: E: devel-dependency glibc-devel
gcc.x86_64: W: devel-file-in-non-devel-package
This looks normal since gcc is a compiler but will be an error for another
package (e.g. an application).
jlaska told me that Fedora QA already uses rpmlint. Have you guys identified
other areas/tests that need special handling or exclusion ? What are those?
Have you thought about the file format? It needs to be easy to maintain and easy
to read - probably just plain text. It also needs to be flexible so that we can
add to it without breaking compatibility. We can probably have a separate file
(format) for every test/package that rpmlint performs.
Just to let you know that I'm happy to work on the rpmlint code and push it
upstream if noone else has spare cycles.
Regards,
Alexander.