$ rpm -qla | grep "(contains no files)" | wc -l 25 it's quite useless. rpm-4.13.0-0.rc1.40.fc25.x86_64
Yes, in this particular case it may be useless. But it can be useful when somebody call "rpm -ql somepackage" and we want to have behaviour of queries consistent. And this always behaved like this so if we changed this, we could break some existing scripts or other tools which use rpm and I think that isn't worth it. Btw what are you trying to count? Don't forget that output of "rpm -qla" contains ghost files, duplicate files (if two packages contain the same file), ...
(In reply to Ľuboš Kardoš from comment #1) > Yes, in this particular case it may be useless. But it can be useful when > somebody call "rpm -ql somepackage" and we want to have behaviour of queries > consistent. And this always behaved like this so if we changed this, we > could break some existing scripts or other tools which use rpm and I think > that isn't worth it. I agree that if we query files for one package - it should be there, but not when > 1 packages. > > Btw what are you trying to count? Don't forget that output of "rpm -qla" > contains ghost files, duplicate files (if two packages contain the same > file), ... I didn't remember exactly, but it was too confusing.
Yup, there's an ancient upstream ticket on the topic: http://rpm.org/ticket/31. Spewing redundant information is not unixy at all, 'rpm -ql foo' should really produce zero output on an empty package unless in verbose/debug mode. Ignoring the issue of potential script breakage, a relatively simple solution would be to change all rpmlog() output to go to stderr instead of stdin/stderr based on level like it now does, and probably adjust a bunch of log levels to silence it in default mode. There are some places like query code which uses rpmlog() for generating "user output", those would need to be changed to fprintf() instead (or add some special log level for that purpose).
RFC patch posted on rpm-maint: http://lists.rpm.org/pipermail/rpm-maint/2016-October/004594.html
I don't see this getting worked on anytime soon, moving to upstream tracking. Once again.