Re: Bug#231235: arabtex font installation is broken

[Florent Rougon <f.rougon@free.fr>]

Hi,

frank@kuesterei.ch (Frank Küster) wrote:

> I had a look at tetex-base's postinst. This is what it does:

[...]

> 4. Check whether /usr/bin/texconfig and fmtutil.cnf exist and texmf.cnf
>    handles the /usr/share/texmf tree, if yes, create format files. This
>    is needed if tetex-base is upgraded without tetex-bin being changed,
>    and has no relation to updmap.

BTW, there is a rather ugly thing done at this point of the postinst:

    if [ -e $TEXCONFIG_P -a -e /usr/share/texmf/web2c/fmtutil.cnf ] && \
        fgrep -q TEXMFMAIN /usr/share/texmf/web2c/texmf.cnf 2> /dev/null && \
        fgrep -q /usr/share/texmf /usr/share/texmf/web2c/texmf.cnf
    then
#       $TEXCONFIG_P font options appendonlydir varfonts
#       $TEXCONFIG_P font vardir /var/cache/fonts
        /usr/bin/mktexlsr
    ...

The fgrep test is seriously wrong. What if TEXMFMAIN and
/usr/share/texmf appear in (maybe even unrelated) comments in
/usr/share/texmf/web2c/texmf.cnf? The fgrep calls prove _nothing_.

Something like:

if [ -x "$TEXCONFIG_P" ] && [ -r /usr/share/texmf/web2c/fmtutil.cnf ] \
   && grep -v '^[[:blank:]]*%' /usr/share/texmf/web2c/texmf.cnf | grep \
        '^[[:blank:]]*TEXMFMAIN[[:blank:]]*=[[:blank:]]*/usr/share/texmf[[:blank:]]*$'
then
    ...

would be more robust... But it wouldn't work if the variable is set
indirectly (like the HOMETEXMF = $HOME/texmf). You can also add
2>/dev/null if it makes fell happy... yes,
/usr/share/texmf/web2c/texmf.cnf is generated (I think) by update-texmf
from tetex-bin, not tetex-base. Gets complicated.

You can also replace [:blank:] by the combination of space, unbreakable
space and tab that you think is appropriate (use ^Q tab under Emacs, ^V
tab under vi or in a shell to enter a raw tab) if you want something
that can't depend on the locale...

> 5. Make links from /etc/texmf/dvips/{psfonts,pdftex,dvipdfm}.map to the
>    respective files. 
>
>    If I understood correctly, these are also the output files of
>    updmap. Thus these configuration actions are not needed to run
>    updmap, but the files generated by updmap will be overridden if it is
>    a fresh install of tetex-base (>=2 ?).

No:

        for m in ${generated}
        do
****************************************
          if [ ! -e ${ETCD}/${m} ]; then
****************************************
            cp ${mapdir}/${m} ${ETCD}
          fi
        done

> It seems, calling updmap with tetex-{base,bin} being unpacked, but
> unconfigured is safe. At least with respect to tetex-base, I didn't
> investigate tetex-bin in detail.

I am not saying it will not work (in the current state of things), but I
think it is wrong for a package like arabtex not to depend on
tetex-base, simply because only tetex-base provides
/etc/texmf/updmap.d/00updmap.cfg. You cannot pretend your are going to
build correct map files when you run updmap without guaranteeing
*yourself* that this file exists ("not guaranteeing oneself" meaning
here: hoping that one of the packages one depends on depends on a
package that contains the file one needs).

-- 
Florent