Red Hat Bugzilla – Bug 50270
gnome-print-0.29-1 creates /etc/gnome/fonts/fontmap2 without taking ownership of it
Last modified: 2007-04-18 12:35:16 EDT
The postinstall script from gnome-print creates /etc/gnome/fonts/fontmap2,
but its spec file doesn't know this. Since this file is always created
when this package is installed, its spec file should take ownership of it
as a config file.
A package can't take ownership of a file not distributed with it.
And if I distribute one file, the overwrite it in the install,
a .rpmsave file will always be created when upgrading -- not
a desirable consequence.
Doesn't seem much different to me than:
$ rpm -qf /etc/lilo.conf
file /etc/lilo.conf is not owned by any package
$ rpm -qf /etc/ld.so.cache
file /etc/ld.so.cache is not owned by any package
So, my first instinct anyways is that it is OK the way it is.
As a counter-example, see how /etc/rndc.conf is handled by the "bind" package.
/etc/lilo.conf is a bad example because the lilo package doesn't create
/etc/lilo.conf. It's created by a human being, and therefore it's reasonable
for it not to be part of any package.
Similarly, /etc/ld.so.cache isn't created automatically by the installation of
On the other hand, the file referenced by this bug report is *always* created by
the package during installation, and thus should be claimed by the package.
To get around the .rpmsave problem you mentioned, you could either do what bind
does or have a preuninstall script that restores these files to their empty
contents so that the .rpmsave file won't be created during the upgrade.
I just upgraded to gnome-print-0.30-4, and now I've got another file that isn't
owned by any package -- /etc/gnome/fonts/gnome-print-rpm.fontmap. This problem
is getting worse, not better :-).
Actuallly, it's not worse, its still one file, just a different one.
(Yeah, when packages create files that aren't removed on upgrade,
it's hard to tell)
* Thu Aug 28 2003 Owen Taylor <firstname.lastname@example.org> 1:0.37-7.1
- Ghost /etc/gnome/fonts/gnome-print-rpm.fontmap (#50270, Jonathan Kamens)