Re: Another way to deal with the Font Map Problem
Florent Rougon <f.rougon@free.fr> schrieb:
> 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.
This is not only a good idea, it has the advantage that it actually
works with tetex-3.0, in contrast to the old solution. This week, I
finally managed to implement the old solution cleanly in my experimental
packages, only to find out that it has a design flaw.
The problem is: In the old approach, the file in /etc/texmf/updmap.d/ is
created in preinst, because this is the only place where we can
distinguish whether we are installing from a purged state, or "rc" with
config files present, but the file in updmap.d deleted by the admin.
However, when you do
apt-get install tetex-bin $package_with_such_a_file
the order of events is:
tetex-bin.preinst (nothing of interest)
tetex-bin is unpacked, conffiles are still named *.dpkg-new
$package.preinst (file is copied to its place)
$package is unpacked, conffiles are still named *.dpkg-new
tetex-bin is configured, its conffiles get their real names
tetex-bin postinst: Wooosh.
The postinst finds $package's file in updmap.d, but the files that are
referenced therein are still called *.dpkg-new, and updmap fails (it is
stricter in tetex-3.0).
I think this should occur with lmodern and tetex-2.0.2, too, with the
important difference that updmap, and hence tetex-bin's postinst,
doesn't fail if it does not find some map files. updmap is simply run
once again by lmodern's postinst.
I will add a workaround to my packages (simply create the file in
postinst unconditionally and policy-violating), until I hear from you
about your implementation plans.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: