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

Bug#246818: Bug#213310: omega.map, all map files, and generated map files



Hilmar Preusse <hille42@web.de> schrieb:

> On 10.05.04 Frank Küster (frank@debian.org) wrote:
>
> Hi Frank,
>
>> Yannick, I'm keeping you in as the submitter of the recent
>> omega.map bug, but this is more general. For further information,
>> read http://bugs.debian.org/213310.
>> 
> In that bug I discussed the approach to set just $VARTEXMF too. I
> hesitated to apply it, as I didn't know anything of the side effects,
> e.g. texconfig IIRC reads $VARTEXMF, but I don't know to what
> purpose. 

The purpose is to allow TEXMFMAIN to be on a readonly
medium/partition. We also want this (keep it out of /usr/), but at the
same time we want more: We want configuration in /etc/texmf. We can
achieve this with symlinks in TEXMFMAIN (and patching texconfig if
VARTEXMF is set), or with symlinks in VARTEXMF. I'd prefer the former,
because otherwise we have to create much more directories in VARTEXMF
only to create our symlinks there. Therefore I have patched texconfig in
the latest diff.

> In a private mail I told you that in teTeX beta the
> generated map-files are in different subdirs than the shipped files.
> Hence we need just to set some symlinks and are done. You replied
> that this is a good start to resolve #213310. You changed your mind,
> that's OK with me. I'll have a look at your patch as soon as I have
> time.

Yes, I have changed my mind. Back then, I just accepted that all map
files be conffiles without caring for a rationale. Now I have thought
about it, and I think they shouldn't be conffiles - the reasons have
been outlined elsewhere.

But there's one other reason that I probably have not yet mentioned: In
TeX and LaTeX there is no clear distinction between programs, libraries
and data files. Every non-comment byte influences the behavior, and
could be possibly changed for local customization. (No, I don't want to
put $TEXMFMAIN into /etc...). 

The only thing where a clear distinction between configuration files and
non-configuration files *can* be made is in the files that are used to
configure the behavior of the *binaries*: modes.mf for metafont,
updmap.cfg for updmap, it's output for dvips/pdftex/dvipdfm,
language.dat for ini(pdf)tex, and so on. Keeping updmap.cfg and its
output in VARTEXMF is, however, appropriate because we have an
additional layer, and the configuration is done in updmap.d.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie




Reply to: