Re: Another way to deal with the Font Map Problem
Florent Rougon <f.rougon@free.fr> schrieb:
> However, another solution occured to me that could solve all these
> problems in a relatively nice way, allowing for easy packaging of fonts,
> AFAICS. Instead of trying to bend font packages in such a way that they
> work safely with the current tools, we could make a slight modification
> to update-updmap and add simple a tool for use by font package
> maintainer scripts only, which would allow the fine .cfg files to be
> actual conffiles.
>
> Simply, we would have a file such as
> /var/lib/tetex/disabled-fontmap-cfg-files looking like that:
>
> ,----
> | 10foo
> | 10lmodern
> | 10bar
> | 10quux
> `----
>
> update-updmap would work just as usual, except that it would ommit the
> files whose base names are listed in that file.
That sounds good, really good.
> We would provide a small tool such as dtetex-manage-fontmap-cfg-files[1]
> that would be called:
> - in the postinst of font packages, to make sure their .cfg files are
> not listed anymore in disabled-fontmap-cfg-files (otherwise,
> update-updmap would ignore them);
> - in the postrm of font packages, to add the relevant .cfg files to
> disabled-fontmap-cfg-files [perhaps also to remove them if the
> package is purged in order to clean up the file, if we are *sure*
> that the .cfg conffiles will be removed by dpkg; I don't think this
> is guaranteed in all cases, so maybe we wouldn't do that].
Since the postinst script is called with option purge after dpkg has
finished its work, the postinst (or rather dtetex-manage-fontmap-cfg (we
don't need the trailing -files, do we?)) can check whether the file is
still there and disable only then.
By the way, it is right that dpkg sometimes doesn't delete conffiles on
purge, but as far as I can see this always involves a bug in maintainer
scripts.
One situation were this will occur: Version $a of your package provides,
say, 10lmodern.cfg, but in a later version $b you switch to
90lmodern.cfg for whatever reason, and _don't_provide_an_upgrade_path_
for moving the file, so the old one is also there.
Another possibility is conffiles that are no longer used and simply
dropped from a new version; they will not be deleted. But if they still
will be found and used by the program, you have a bug anyway, and if
they don't matter, they should be deleted them in postrm.
The problem might also occur if a package declares
Replaces/Conflicts/Provides on an other package and doesn't care for
leftover configfiles from the removed, but not purged package. With
Replaces only it shouldn't occur, I think.
> If you think this scheme is a good idea, I'm willing to implement and
> document it (post-sarge).
I think this is a really good idea. It is much simpler in implementation
than what you originally proposed - I have tried to provide
/var/lib/tetex/ (and a README file therein) in my experimental
tetex-base package, and it turned out to be even more complex than for
just one package having its own directory.
Post-sarge, yes, in the sense that it won't be included in tetex-2.0.2
for sarge. But not in the sense that you may lean back and wait for
sarge to be released before you start coding ;-). I would be very much
oblidged to you if you could provide such a scheme for the experimental
packages in preparation.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: