Re: About the updmap and VARTEXMF changes
Florent Rougon <f.rougon@free.fr> wrote:
> "--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
Yes, we discussed it back then, and maybe I didn't raise my objections
loud enough.
> 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.
This should be included in some form in README.Developers, section
3. Maybe also a note in NEWS.Debian is necessary. In this case, the main
text should only describe the present situation, without lengthy
historical explanations.
> \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.
Well, it wasn't updmap that was changed, rather the fact that now
$VARTEXMF is defined.
> If you accepted the recommended modifications to texmf.cnf that
> introduced the VARTEXMF tree in front of TEXMFMAIN,
This has to be accepted (in fact I didn't check whether placing it after
TEXMFMAIN works also). If there's no $VARTEXMF in $TEMXF, the package
will break completely. We also have some code in postinst forcing it
into texmf.cnf.
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).
I'd suggest:
If two files with the same name exist in /etc/texmf/dvips/ and in
/var/lib/texmf/dvips/config, the ones under /var/ will take
precedence, since TEXMFMAIN is searched after VARTEXMF. Unique files
in /etc/texmf/dvips/ will still be found because
/usr/share/texmf/dvips/config is a symbolic link to /etc/texmf/dvips
The next paragraph just explains "shadowing" in detail, and could be
left out if the preceding one is good enough, right?
> 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...
I don't think we'll do any big tweaks in postinst for sarge, and we'll
have plenty of time to think before coding for etch...
> 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.
But still such packages should somehow care for changes in tetex. If we
put the new paragraph in NEWS.Debian, that should be enough.
> 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...
Oh, you're right. The code is in remove-oldmaps yet, but for the map
files we generated, I had planned to remove them without asking.
> /etc/texmf/updmap.d/10lmodern.cfg[1]
[...]
> [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,
If they didn't change it, and it is a conffile (i.e. shipped in the
deb), then dpkg will have replaced it. If they changed it, they will
have been asked, and at least find a 10lmodern.cfg.dpkg-new file with
the new information.
> 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).
Ah, I didn't remember.
> 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. :-/
Yes, I think ucf can help. Or fixing dpkg to include ucf's
functionality...
> (The good thing is, sarge installations will be OK.)
And upgrades from woody also.
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: