----- "Alexander Todorov" <atodorov(a)redhat.com> wrote:
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> ?
Yes, I would love to if rpmlint has internal support for per-package
config file (the actual path doesn't matter). There are some advantages:
1. rpmlint can use it even if you don't have that package installed, it
simply extracts it from the rpm file.
2. You can be sure that only relevant config file gets loaded for your
package. That means you don't waste performance on loaded several
thousand other config files and also you can be sure that no other
config file by accident influences your results.
3. You surely don't want to have several thousand *.config files directly
in /etc/rpmlint, it would be a mess. At least one more dir is needed
to keep it separated.
4. These files should be stored in /etc at all I believe. They are not
config files, which a system administrator would like to change.
They are more like a definition file. Those file will be changed only
by the package maintainer and will be distributed with next package
release. They should not be in /etc.
5. Package maintainers get the same output on their machines as we do
on ours.
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.
I'm afraid it is not so. Take this example:
addFilter('audit.* /etc/audisp/plugins.d 0750')
This will filter not only results for audit package, but also for audit-libs
(same source package) and audit-viewer (different source package).
I think regular expressions are not enough in this case, you will get
similar collisions all the time. Also, it would be hell to manage.