Software Management call for RFEs

Nicolas Mailhot nicolas.mailhot at
Thu May 23 13:41:11 UTC 2013

Le Jeu 23 mai 2013 13:20, Panu Matilainen a écrit :
> On 05/22/2013 08:22 PM, Nicolas Mailhot wrote:
>> Hi,
>> Please clean up the distaster package verification is.
>> rpm -Va is so incomplete it spawned rpmlint, package-cleanup and not
>> doubt
>> others I forget about.
> There's probably some overlap in what those utilities do but generally I
> see them as addressing different kinds of issues. 'rpm -Va' is about
> verifying the installed packages are intact wrt what the package
> originally contained. rpmlint on the other hand is more about detecting
> common packaging mistakes - things that are technically legal packages
> but ones that are not packaged by "best practises", including distro
> policies and all.

Sure, but there is no reason the two kinds of problems must be addressed
with different tools and different output conventions. And in fact (as
seen in the gdm case) the fact that a runtime script changed the
permissions after install (rpm -Va perimeter) was a symptom of a packaging
problem (rpmlint perimeter). The perimeter limits exist in our mind, the
actual problems rarely appear at just one point in the package lifecycle.

>> Even for the most basic checks its output is so useless and difficul to
>> parse we've seen a critical path package like gdm shipped with the wrong
>> file permissions without anyone noticing.
> No disagreement there... if you have concrete proposal on how 'rpm -Va'
> output should look like to be easily parsable and sane, I'm all ears.
> Ditto if you know of some other tool performing similar function with
> sane(r) output.

I'd like rpm -Va output to be libified so:
1. it can be plugged into emacs or eclipse and provide run-time spec
edition checking
2. a service can periodically execute system sanity checks, log errors to
journald (or even to an healthcheck gui indicator) and warn about
dangerous modifications to installed packages or packages that do not
respect sanity checks and pollute the system
3. it can still be called with a CLI

And the output should have some verbosity level, at sparsest level just
one status line per problem package, then one line per problem in a
package, then detailed description per problem (for example file
permission is XXX, should be YYY) then full howto-like explanation per

Non-problems like timestamps should not be reported at all (only report
actual problems something can be done at).

I'm quite sure trying to actually do something with the error output will
help define how it should look like.


Nicolas Mailhot

More information about the devel mailing list