Bug#246818: Deleting conffiles in maintainer scripts and the need to resurrect them later...
severity 246818 important
stop
Frank Küster <frank@debian.org> wrote:
> This file is listed as "oldfile" in tetex-base's config script, and
> removed if the user takes the default answer to the debconf
> question. This question was introduced with the first version in our
> CVS, i.e. 1.0.2.20021025-4 or earlier. I guess the file is needed again
> since tetex 2.0.
This is even more weird. I have removed the code that deletes this file
(it was in the config script of tetex-base), but this does not help.
omega.map is a conffile of tetex-extra, and dpkg won't create conffiles
that have been deleted.
So in order to get the file, everybody has to purge tetex-extra and
reinstall it.
==================================================================
LESSON:
Don't remove obsolete conffiles in maintainer scripts - you might need
them again in later versions!
==================================================================
Well. But we've done it. Currently omega.map is the only one that really
needs some action, but we should also do something about the others. For
omega.map, I would suggest we (once) ask a debconf question with low
priority, defaulting to resurrect the file by copying from
/usr/share/tetex-extra/.
For the others I see two possibilities:
- Do not remove those files any more, just let them lie around,
cluttering the directory. Ugly, but we are on the safe side should we
ever need one again
- Move the files to some other directory (like
/etc/texmf/dvips/obsoletemaps/), being able to copy them back in
future postinst, should we need them. Complicated and perhaps
error-prone, but it gives a cleaner /etc/texmf/dvips.
What do you think?
On the other hand, we could also ask why we consider font-specific map
files to be configuration files at all. Of course there can be
situations where one wants to change something there in order to get a
different behaviour of some program. But that's also possible with
nearly every text file in /usr/share/, and itself not a sufficient
argument for a file to be a configuration file. If I want to change the
behavior of gnus.el, I make a copy in /usr/local/share (or somewhere
else) and change the copy.
Of course this does not apply for the generated map files and for the
config* files.
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: