Re: rpmlint improvements

[Kamil Paral]

----- "Alexander Todorov"  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.

rpmlint improvements

[Alexander Todorov]

Kamil Paral wrote:
> 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.

Can you explain? Do you mean that rpmlint will read its default config + 
/usr/share/rpmlint/whitelist/<package> ? Currently it does read the default 
config + /etc/rpmlint/*config which is a bit different but can serve the same 
functionality if whitelisting filters begin with the package name.

--
Alexander.

rpmlint improvements

[Seth Vidal]

On Thu, 2010-10-07 at 09:53 -0400, Kamil Paral wrote:
> 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.

one config file per pkg? or one per branch per package?

Would it make since to have:

fedpkg rpmlint

which checks the pkg in the branch you're currently in

using .rpmlint as the config for that pkg, if it exists.

and then have autoqa draw the .rpmlint file from the git branch it is
building in the same way?

then the pkger has control over it and if there is a different
maintainer for el5 vs f13 they don't have to quibble over rules.

thoughts?
-sv