Re: Another way to deal with the Font Map Problem
Florent Rougon <f.rougon@free.fr> wrote:
> 'kay... I'll have a look at it.
There is still a problem with this scheme. I have solutions, but it will
be a bit less simple than was previously described, unfortunately.
The problem is: who is going to remove the file we called
/var/lib/tetex/disabled-fontmap-cfg (the one storing the list of .cfg
files that update-updmap should ignore)? We were all thinking---or not
thinking at all---tetex-bin or tetex-base, I guess, but I think it is
possible to purge tetex-* while keeping $fontpackage installed. It will
just be deconfigured (if it depended on one of the tetex packages).
If one of the tetex packages were to delete the file on purge, the
following scenario could happen:
1. install tetex-* and $fontpackage
2. remove-but-do-not-purge $fontpackage
3. purge tetex-*
4. reinstall tetex-*
The information "$fontpackage is removed-but-not-purged, update-updmap
should therefore ignore its .cfg files" would be lost in step 3, and
consequently, update-updmap would try to use its maps in step 4.
One way to avoid this problem would be to use dpkg to store the
complementary information: "$fontpackage is installed and has this and
that .cfg files under /etc/texmf/updmap.d/". For instance, supposing
$fontpackage ships /etc/texmf/updmap.d/{10foo,80bar}.cfg, it would
include _in the .deb_ a file called
/var/lib/tetex/fontmap-cfg/$fontpackage.list that would contain:
10foo
80bar
update-updmap would only consider the files whose base names are listed
in one of the /var/lib/tetex/fontmap-cfg/*.list files. When $fontpackage
is removed (or purged), /var/lib/tetex/fontmap-cfg/$fontpackage.list is
removed, which will cause update-updmap to ignore $fontpackage's .cfg
files. When it is reinstalled, the file reappears and the .cfg files are
not ignore anymore by update-updmap. The tetex packages can be erased
meanwhile, causing no particular problem (because the information about
$fontpackage is stored in $fontpackage itself, not in the tetex
packages).
Well, the only tiny problem is that user-added files under
/etc/texmf/updmap.d/ will be ignored by update-updmap since they would
not be listed under /var/lib/tetex/fontmap-cfg/. ;-)
Possible solutions are:
(a) split /etc/texmf/updmap.d/ into two parts, one for .cfg files
provided by packages (whose files update-updmap would ignore
unless they are listed under /var/lib/tetex/fontmap-cfg/), and one
for user-provided .cfg files (whose files update-updmap would
always use);
(b) force users to use a particular naming scheme for their .cfg files
(such as XXlocal-foo.cfg, where XX stands for two digits), so that
they are always used by update-updmap;
(c) similarly, force font packages to use a particular naming scheme
for their .cfg files to distinguish them from user-provided .cfg
files;
(d) add a magic comment[1] at the top of the .cfg files that are
provided by packages, which would tell update-updmap to apply the
ignore-unless-listed-under-/var/lib/tetex/fontmap-cfg/ policy.
I fear that (a) and (b) would be painful to migrate to, as well as (c)
which would additionally perhaps look a bit ugly (many file names with a
common part under /etc/texmf/updmap.d/...). (d), OTOH, does not sound
*that* awful. We would just have to include the magic comment in the
existing package-provided .cfg files, which should be easy since they
would be conffiles in this scheme.
What do you think? Better ideas?
[1] update-updmap could strip it so as not to clutter updmap.cfg.
--
Florent
Reply to: