Re: Nasty surprise with updmap-sys

Sarantis Paskalis <[email protected]> Mon, 7 Nov 2005 10:36:41 +0000 (UTC)
Newsgroups gmane.comp.tex.tetex.general
Message-ID <[email protected]>
Reinhard Kotucha <reinhard.kotucha <at> web.de> writes:

> Hi Michal,
> to avoid such surprises in the future, please read the documentation.
>
> I don't know what you expect, but I expect that a new version of teTeX
> will not overwrite my local configuration.

Hi,

(posting through gmane, majordomo does not seem to like me)
I would agree with Michal that the behavior of updmap-sys is problematic.
It should pick a configuration file location and stick with that.  The
location of updmap.cfg should remain consistent.

> And how do you modify files in texmf and texmf-dist if these
> directories are on a read-only file system?  How do you adapt local
> configuration files for particular hosts if the main texmf trees are
> on a remote file system?

Yes, but:

- If the texmf trees are read only, _and_ the default configuration tree
is in texmf, then no configuration change is allowed.

- If the configuration tree is texmf-config, then all the configuration
files should be in texmf-config in the first place.  If no texmf-config
tree is present, then an error should be produced, and not silently use
updmap.cfg in a different tree (texmf).
 
- If backwards compatibility is also desired, then the configuration
files should stay where they were first found (i.e. if updmap.cfg is
found in /usr/share/texmf/web2c/updmap.cfg and is updated, then its
modified version should be written in the same location).

I understand the reason for putting modifiable (not modified)
configuration and variable files in a different location, but I also
find the selective behavior of updmap-sys odd.  Please note that I
just refer to updmap-sys script, not updmap.  

A call to updmap-sys (without the --enable or --disable option) would
read /usr/share/texmf/web2c/updmap.cfg just fine.  A call to updmap-sys
(with the --enable or --disable option) would write the new updmap.cfg
to a different location, and the output of texconfig-sys conf would be
different.  This is without an administrator changing any options or
defaults in the configuration, just adding a font.

My proposal would be to change the behavior of updmap-sys is one of
the following:

1. Demand that the configuration files are in TEXMFSYSCONFIG and
TEXMFSYSVAR.  If they are not found there, produce errors.

2. If backward compatibility is desired, and configuration files are
found and used in different locations (other than TEXMFSYSCONFIG and
TEXMFVAR), place their modified versions (after running updmap-sys)
in the places where they were originally found.

The second alternative does not break anything AFAICS, and follows
the principle of least surprise.

Please reconsider.

Thanks,

Sarantis Paskalis