----- "Alexander Todorov" <atodorov(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/autoqa-devel