[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Problem with the "updmap scheme" when a font package is in an "inconsistent state"


While testing tex-common 0.24, I found a problem with the "updmap

First, you have to know that in lmodern 1.00-1, I use the specific map
files (lm-ec.map, etc.) instead of the monolithic lm.map, because the
upstream-provided lm.map looks incomplete (some math fonts declared in
the specific map files aren't declared in lm.map).

Therefore, I had to change 10lmodern.cfg to reference the specific map
files instead of lm.map. Easy, it's a conffile.

Now, I installed lmodern 1.00-1 today but didn't upload it to any of my
apt sources (except the Debian archive, but it's not already published
there, consequently my apt still cannot see lmodern 1.00-1).

Then, I removed it, as well as tetex-bin and reinstalled both packages
with apt:

  Unpacking tetex-bin (from .../tetex-bin_3.0-16_i386.deb) ...
  Unpacking lmodern (from .../lmodern_0.99.3-4_all.deb) ...
                  since 1.00-1 is not yet in any of my apt sources

  Setting up tetex-bin (3.0-16) ...
  Running fmtutil-sys. This may take some time. ...
  Running updmap-sys. This may take some time. ...
  updmap failed. Output has been stored in

Ugh. Baad. The reason is simple: at this point, lmodern is inconsistent:
its map files are those of 0.99.3-4 (they were just unpacked), i.e. only
lm.map, but its conffile 10lmodern.cfg is still that of 1.00-1 (the
previously configured version) because lmodern hasn't been configured
yet. This conffile references lm-ec.map and others instead of lm.map,
which as we said doesn't exist since the unpacked lmodern version is
0.99.3-4... updmap-sys failed because it couldn't find lm-ec.map.

So, the problem is running update-updmap when a font package is in a
potentially inconsistent state (unpacked but not configured). This
doesn't fail, but running updmap-sys before the inconsistency is fixed
does fail.

What we would like to do is have update-updmap ignore 10lmodern.cfg not
only when lmodern is removed-but-not-purged (which works, as usual), but
also when its conffiles (here, 10lmodern.cfg) haven't been updated to
the last version (by dpkg).

I think this can be done by testing for the existence of
/etc/texmf/updmap.d/10lmodern.cfg.dpkg-new, but it's a bit ugly.
If someone has a better idea, I'm all ears. :-)

[ checking /var/lib/dpkg/status or similar is not an option, because
  update-updmap is run as part of lmodern's configuration process,
  therefore we cannot simply say: "update-updmap will ignore
  10lmodern.cfg whenever lmodern isn't configured." Otherwise,
  lmodern could never be configured properly.

PS: when you upgrade from 0.99.3-4 to 1.00-1, you'll probably not see
    the problem, unless you:
       - first unpack lmodern 1.00-1;
       - then run update-updmap and updmap-sys before configuring
         lmodern (which can happen if you're installing or upgrading
         tetex-bin at the same time, for instance).

PPS: another "solution" is to use a monolithic lm.map again, but this
     would be hiding the problem under the rug...


Reply to: