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

About the updmap and VARTEXMF changes



Hi,

While trying to see what was happening in
<[🔎] 87sma157yd.fsf@alhambra.bioz.unibas.ch> (cf. bug #269416), it occurred
to me that the updmap change in tetex-bin 2.0.2-17 was badly affecting
lmodern. This is because I used updmap with
"--outputdir /etc/texmf/dvips" in the maintainer scripts. I did this
becaused it vaguely seemed to be the best way according to a message in
the log for a tetex bug report I had read at the time of the
packaging... and it made absolutely no difference at that time, since
without the option, updmap would have put the generated files under
/usr/share/texmf/dvips/config, which was and still is a symbolic link to
/etc/texmf/dvips.

The consequence is that if you installed the tetex packages with
tetex-bin >= 2.0.2-17 before lmodern << 0.92-3, the latter would update
the map files in /etc/texmf/dvips and not the ones in
/var/lib/texmf/dvips/config, which with the recommended settings in
tetex-bin >= 2.0.2-17, take precedence over the ones in
/etc/texmf/dvips. So, the lmodern fonts would not be seen by Dvips,
pdfTeX, etc. until the next updmap run that would update the map files
under /var/lib/texmf/dvips/config... which happens every time one of the
tetex packages is upgraded, which is why this problem managed to remain
undetected during all of August. Bah.

This is fixed in lmodern 0.92-3, which has been uploaded by Sébastien
Bacher today, so it should be OK for sarge.

While updating the comments in the default
/etc/texmf/updmap.d/10lmodern.cfg[1], I wrote the following paragraphs
and then realized that they actually belong to tetex-bin, not lmodern.
>From a grep under /usr/share/doc/tetex-{bin,base}, I don't have the
impression that such a blurb already exists, so I suppose it could be
added.

\begin{Consequences of the updmap and VARTEXMF changes for the old map
       files that could still reside under /etc/texmf/dvips/}

  Earlier versions of the Debian teTeX packages generated the final map
  files such as psfonts.map under /etc/texmf/dvips/. In tetex-bin
  2.0.2-17, updmap was changed to write these files under
  /var/lib/texmf/dvips/config/, making it clear that they should not be
  modified by the administrator.

  If you accepted the recommended modifications to texmf.cnf that
  introduced the VARTEXMF tree in front of TEXMFMAIN, map files
  generated by an updmap from tetex-bin 2.0.2-17 or later will shadow
  any existing map files with the same name but under /etc/texmf/dvips/
  since /etc/texmf/dvips is found when searching under TEXMFMAIN since
  /usr/share/texmf/dvips/config is a symbolic link to /etc/texmf/dvips
  (at least in tetex-base 2.0.2b-3 and several earlier versions).

  As a consequence, if you are using the recommended setup for tetex-bin
  (i.e., if you have a VARTEXMF tree that comes before TEXMFMAIN in your
  texmf.cnf), then automatically generated map files under
  /etc/texmf/dvips/ such as psfonts.map will not be seen by the relevant
  programs. Instead, the programs will only see the files with the same
  names under VARTEXMF (precisely: in /var/lib/texmf/dvips/config/).

\end{...}

I checked the packages that depend on tetex-bin for a similar problem as
in lmodern 0.92-2 (using updmap with --outputdir=a place that is not the
right one anymore). I didn't find anything except an code fragment that
is commented out in tetex-base-2.0.2b/debian/postinst:

  # NEED MORE INVESTIGATION! it seemed safe not to do this.
  #    if [ -x ${UPDMAP} -a -x /usr/bin/updmap -a -f ${BASEMAP} -a -x /usr/bin/kpsewhich ]; then
  #       MAPTEMP=`tempfile -p updm`
  #       ${UPDMAP} -vpfile -p updm`
  #       /usr/bin/updmap --cnffile ${EUMAPC} --outputdir /etc/texmf/dvips 2> ${MAPTEMP}
  #    echo "Output of updmap is in ${MAPTEMP}"-outputdir /etc/texmf/dvips 2> ${MA

This should probably be fixed or got ridden of to avoid seeing the
problem arise again if this ever gets uncommented...

In case you also want to play, here is how:

  1. Download and extract the interesting packages:

      for p in \
        $(grep-available -n -F Depends -s Package -e '\<tetex-bin\>'); do \
          apt-get source "$p"; \
      done

     Note: this does not cover all packages that could exhibit the
           problem: one could imagine a font package that calls updmap
           and friends only if they are available; such a package
           wouldn't have to depend on tetex-bin.

  2. Run from the same directory a script similar to:

      #! /bin/sh

      find . -type d -mindepth 1 -maxdepth 1 | \
        while read package; do
          echo '----------------------------------------------------------'
          echo "Package: $package"
          echo
          grep -iErC 2 -e '\<updmap\>' "$package"
        done

Finally, I don't know what the tetex packages do with the generated map
files under /etc/texmf/dvips/, but I think they are confusing for users
since they are not used as soon as they have a counterpart with the same
name under VARTEXMF... They should probably be deleted, or renamed, or
whatever but not let lying there...

  [1] I fear that users of lmodern << 0.92-3 who didn't purge it before
      installing the latest version will still have the previous default
      version for this file, which mentions /etc/texmf/dvips as the
      output directory for updmap, which is untrue since
      tetex-bin 2.0.2-17. This file is not (cannot be) a conffile and I
      haven't investigated a mechanism for merging changes in the new
      default file yet, because I really didn't forsee the file changing
      anytime soon (and apart from the comments, it indeed did not
      change). Maybe ucf will help, but for now, we'll have to live with
      a slightly misleading /etc/texmf/updmap.d/10lmodern.cfg on a few
      installations. :-/
      (The good thing is, sarge installations will be OK.)

-- 
Florent



Reply to: