jik:/usr/lib/rpm!290> rpm --verify XFree86-truetype-fonts
.M...... g /usr/X11R6/lib/X11/fonts/TTF/fonts.scale
jik:/usr/lib/rpm!291> rpm -q XFree86-truetype-fonts
As far as I know, I havne't made any modifications to the files owned by this
package that might require me to have different local versions of these files,
so there shouldn't be any errors from rpm --verify.
fonts.scale is generated at install time and is a transient file.
fonts.alias does not exist in the distribution, however, it is a valid
file which *could* exist should a user create one in that directory, in
which case the package is set to own the file. The fonts.alias file is
NOT considered a config file, since config files upon upgrade get either
renamed to .rpmsave, or the new version gets .rpmnew and we both don't want
that to happen, and there is no need for it to happen. "missingok" is
the flag that would be relevant in this case, however that flag is not
relevant except for config files which fonts.alias is not for these
So, I'm not sure how this should be handled, if at all, since RPM does
not seem to have flags to flag these files in the way they need to be
flagged. I'll leave the bug report open in case someone else has a
better idea of how to deal with it. One possibility I can think of
is to remove the %ghost fonts.alias file entirely and make it unowned.
That would then leave any fonts.alias file created by the user unowned
by any package and an uninstall would make the directory unremovable.
The fonts.scale file however is 100% transient and not a statically owned
or installed file. It is generated post install, and whenever else
the xfs initscript or some other event causes it to be regenerated, so
the MD5sum for it is irrelevant.
Closing as dupe of 68933 for tracking
*** This bug has been marked as a duplicate of 68933 ***