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

Re: 2.99.8: updmap output directories



Thomas Esser <te@dbs.uni-hannover.de> wrote:

>> (we don't discriminate between TEXMFMAIN and TEXMFDIST, this is the
>
> Ok, but please make sure that all links in texmf/doc/index.html and
> texmf/doc/tetex/TETEXDOC.* work properly.

Yes, I'll have to look at this anyway. Does the mkhtml script currently
work? 

>> TEXMFDIST = not used
>
> The idea of TEXMFDIST was that people can just replace that tree by the
> content of a new texmf tarball. By merging the TEXMFMAIN content into
> that tree, this is no longer possible as people would loose e.g. their
> pool files.

Yes, that was also what somebody (Karl Berry?) told me back then. But on
a Debian system and probably every Linux distribution with a package
management system, /usr/share is the sole realm of this package
managment system. If the user wants to use a more up-to-date texmf
tarball, he can still unpack it in TEXMFLOCAL, but if he deletes any
files that the package management installed (be it below TEXMFMAIN or
TEXMFDIST) and replaces them by something else, he has messed up his
system. 

So this is not an option for a Linux distribution, and the distinction
between TEXMFMAIN and TEXMFDIST is meaningless. On the other hand,
because there is a package management system, it is easy to install a
more up-to-date version of the package derived from tetex-texmf...tar.gz
and still keep the pool files derived from an older tetex-src...tar.gz
in the same TEXMF tree.


>
>> TEXMF = {$TEXMFHOME,!!$TEXMFCONFIG,!!$TEXMFVAR,!!$TEXMFLOCAL,!!TEXMFSITE,!!$TEXMFMAIN}
>
> This cannot ensure that texconfig works. If someone has a copy of
> config.ps in $TEXMFHOME, than texconfig would still save a modified file
> in $TEXMFCONFIG which means that the changed file will be hidden.

Which is exactly what I wanted (but see below). I assumed texconfig was
a system-wide configuration tool, and on multi-user systems only root or
some group of priviledged users will be able use it and to make changes
to $TEXMFCONFIG. Everybody should be able, however, to override such
system-wide settings using TEXMFHOME. This is how I thought up to now
texconfig was meant.

> My idea was the following: trees like TEXMFHOME, TEXMFLOCAL and TEXMFSITE
> should be free from config files *unless* the user sets TEXMFCONFIG to one
> of those. By searching $TEXMFCONFIG first, texconfig would always store
> the modified files into the right tree. If some user wants to store more
> than just additional fonts / macros in his TEXMFHOME (e.g. also store
> config files there), he should set TEXMFCONFIG.

Ah, this is new to me. So you mean that now that texconfig respects
TEXMFCONFIG, it is no longer a tool for system-wide configuration, but
should instead be used by the actual users. This is a really nice idea.

(However, for us Debianists it creates an additional support problem,
 because the more configuration items people have or set in their home
 directory, the less robust is their installation to changes in packaging
 or changes made by you, and integration of additional packages can no
 longer be done by the package management system for these users.)

Is it also possible to create custom format files? Great feature from a
user's point of view, support hell >:-|.

Anyway, it is a nice feature. I would only suggest that you clearly
point out in the manpage and html documentation (didn't look at the
latter yet) that this is meant for *user-specific* configuration in the
default setup. We distributors can well learn it discussing with you,
but administrators of bigger sites who were used to using texconfig
should be warned.

But this also means that for our system-wide configuration which is
connected to package management, we cannot rely on texconfig and
TEXMFCONFIG and must work as if they didn't exist.

> TEXMFCONFIG, not TEXCONFIG (which also exists). But, yes, you are right.
> On the other hand, the idea of the new texconfig is that a user can set
> TEXMFCONFIG and define a new destination for changed config files. If you
> remove $TEXMFCONFIG from the list in TEXMF, the user would also have to
> set TEXMF to make sure his tree is actually used. Not very convenient...

Yes, now I understood this.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



Reply to: