jik:/usr/lib/rpm!290> rpm --verify XFree86-truetype-fonts missing /usr/X11R6/lib/X11/fonts/TTF/encodings.dir missing /usr/X11R6/lib/X11/fonts/TTF/fonts.alias .M...... g /usr/X11R6/lib/X11/fonts/TTF/fonts.scale jik:/usr/lib/rpm!291> rpm -q XFree86-truetype-fonts XFree86-truetype-fonts-4.2.0-52.01 jik:/usr/lib/rpm!292> 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 purposes IMHO. 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 ***