----- "Alexander Todorov" <atodorov(a)redhat.com> wrote:
Hi all,
finally I've had the opportunity to play with additional rpmlint
config files.
Current version will read all files that match /etc/rpmlint/*config.
See
https://www.zarb.org/pipermail/rpmlint-discuss/2010-September/000861.html
for more info.
If we put our configuration there then the changes are in effect on
the next
rpmlint run. Attached is a config file for the audit package which
will filter
out all errors/warnings about non-standard permissions. I've tested it
and it
works well.
It looks like what's left to do on our side is to scan all packages
and decide
what we want to filter and what is a real error. Also decide between
centralized
vs. per package configuration and start creating those config files
with help
from devel.
My vote is for the centralized approach and the exclusion rules be
administered
by QE folks. What are your thoughts?
Hello Alexander,
thanks for your work. My opinion is similar to jlaska's.
1. If some is going to be a central authority, I don't believe it should
be QA. We don't have the manpower for doing this, nor the required
knowledge (at least I don't have it -- I'm not a package maintainer and
I won't be able to decide for many requests whether they are valid or not).
This whole process seems to me very similar to package review process,
so packaging team could be better suited for this. Anyone, I'm sure FESCo
would have a word in this.
2. I would vote for the permissive way rather than restrictive way.
Permissive way is the way of Fedora. Compare it to the package review.
There is a package review in the beginning, but after that noone really
approves your changes, so you can change practically anything, even
contrary to the guidelines. Someone can report you a bug against your
spec file, but that's it. We just rely on good behavior and dutifulness
of the maintainer. It seems weird to me to have one process with all
that freedom and another process (rpmlint output whitelisting) really
restricted.
3. To ensure people don't hide problems with simply whitelisting every
error message, a document with proper guidelines should be created.
Maintainers then can refer to these guidelines or ask in devel-list.
Still, there may be some maintainers who simply ignore the guidelines
and whitelist everything, sure. In this case, we can do regular/irregular
random/all-packages review and check whether all the whitelist definitions
are valid. (Actually I would love to see this process even for package
review, every package's spec file should be re-evaluated every few years.)
That surely needs some manpower, yes. Probably a similar manpower to the
centralized approach. The advantage is that a lack of manpower does not
block the process, and also we want to keep the maintainers happy with
Fedora. Centralized approaches usually don't achieve that. Surely we won't
have everything 100% correct this way. But things never are 100%.
Some technical details now:
A. From my opinion it's pretty obvious I would like to see one config file
per package, distributed in that package -- the "lintian way". Those config
files could be installed into /usr/share/rpmlint/whitelist/<package> or
similar location. We can already use this approach for autoqa -- we can
extract this file from the binary package (or similarly named file for
the source package) and provide it with --file option to rpmlint. But, it
would be very beneficial if upstream rpmlint also gained these capabilities,
the maintainers would then see the same output on their localhost as the
output provided by autoqa. So, convincing rpmlint upstream to support these
lintian-style per-package config files would be absolutely great.
To close it up -- by following the KISS principle, we should start small.
We may have different ideas on centralized/distributed maintenance, but we
still need the plumbing, either way. We should discuss our needs with rpmlint
upstream in the first place. Then we can start a test round by asking
interested maintainers to create their whitelist files. Based on the result
we can then decide what the future approach should be.