rpmlint improvements

Kamil Paral kparal at redhat.com
Fri Sep 24 15:50:29 UTC 2010


----- "Alexander Todorov" <atodorov at redhat.com> wrote:

> 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?

Hello Alexander,
thanks for looking into this and sorry for late response.

The big difference between lintian and your proposed solution is that
lintian allows to specify "overrides" inside the affected packages [1]
(files located at /usr/share/lintian/overrides/<package> or at 
debian/source/lintian-overrides), but your solution centralizes all those
files in a single package rpmlint-data.

I wonder what the better approach is. Per-package solution obviously gives
more freedom (and trust) to individual package maintainers and is easier
to manage (for them). Centralized approach is stricter (you have to ask
for inclusion, review process can be easily enforced), therefore quality
may be higher, on the other hand it may annoy and discourage a lot of people.
("Just another set of policies to follow.")

Originally I was thinking about the per-package (lintian-like) approach.
My idea is that we can still apply some policies on top of it, but it is
much more convenient for package maintainers in the rest of the cases.

The policy might look like: Every line whitelisting an Error message must
be sponsored by some different package maintainer. On the other hand,
Warning and Info messages might be whitelisted without restrictions.

That's only one example of a possible policy, certainly there is plenty
of solutions.

As Michal Scherer mentioned [2], rpmlint already supports "config files"
in which we can filter out some output (based on regexp I think). So we are
already able to do this inside autoqa - just read the per-package definition
file, create custom rpmlint config and run rpmlint with this config.

Of course, having this feature upstream would be much better for us. The
package maintainers should see the same output when they run rpmlint locally
as they see when rpmlint is run inside autoqa. That is possible only when
rpmlint upstream supports these whitelists definitions directly.

[1] http://lintian.debian.org/manual/ch2.html#s2.4
[2] https://www.zarb.org/pipermail/rpmlint-discuss/2010-September/000861.html

> 
> 
> 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)

An important note here - our proposed solution talked just about whitelisting
some warning/error messages. Also lintian overrides files provide just
whitelisting of output messages.

What you talk about here (and what you sent in your patch [3]) is a little
different. You just don't whitelist some output, you "fix" (override) the
input. For example you don't just define "don't show me the line that warns
me about incorrect permissions on /etc/passwd", but you also define *what 
the correct permissions are*. Per package.

That is a little different (and somewhat harder task). I don't know whether
rpmlint developers will be inclined to so big change (redefining what the
correct input is). But allowing output whitelisting per-package could be
easier to convince them to adopt.

>From my point of view, I would rather start with simple whitelisting too.
Your approach seems to bring more challenging tasks and I think it's better
to start small.

What do you think?

[3] https://www.zarb.org/pipermail/rpmlint-discuss/2010-September/000860.html

> 
> * 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.

Your effort is greatly appreciated, thanks.

> 
> Regards,
> Alexander.
> 
> 
> _______________________________________________
> autoqa-devel mailing list
> autoqa-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/autoqa-devel


More information about the autoqa-devel mailing list