How to install system wide packages without requiring an ls-R database (with texlive)?

Question

Question

How can I install packages for system-wide use, but without requiring the ls-R database to be updated?

Background

The texlive documentation indicates that user specific packages should be placed in TEXMFHOME while packages for multiple users should be placed in TEXMFLOCAL (both of which are organized by the TeX Directory Structure (TDS)).

On your system, these locations can be found by using kpsewhich (they are configured as part of the installation, not just as environmental variables):

kpsewhich -expand-var '$TEXMFHOME'    
kpsewhich -expand-var '$TEXMFLOCAL'

As pointed out in this answer, the TEXMFHOME solution does not require the ls-R database to be updated: packages can just be added here and they will be found.

The TEXMFLOCAL location, however, requires that mktexlsr (texhash) be run to update the ls-R database (which must be done as root if permissions are properly set).

Is there a similar location to TEXMFHOME that does not require an ls-R database for system-wide use?

The use case is that a user on a shared system maintains a package that we host in TEXMFLOCAL. Whenever they change the names of files, the local ls-R database needs to be updated by an administrator. How can we allow the user to modify the package – including changing file names if needed – without requiring an admin to update ls-R?

I realize that there will be a performance hit if the database is not used, a separate tree should probably be used. Also, I am sure that the settings for TEXMFLOCAL could probably be adjusted (by removing it from the TEXMFDBS?) to obviate the need for ls-R, but I am looking for a "standard" solution that meshes with the documented texlive system behaviour.

Answer 1

Path expansion and database search are documented in the kpathsea and web2c documentation (both available with texdoc).

Quoting the kpathsea manual (section 3.4.1):

If a particular path element begins with ‘!!’, however, only the database will be searched for that element, never the disk.

Studying texmf/web2c/texmf.cnf we find

% TEXMFLOCAL follows TEXMFMAIN (and precedes TEXMFDIST) because the
% files in TEXMFMAIN are tightly coupled with the particular version of
% the distribution, such as configuration files.  Overriding them would
% be more likely to cause trouble than help.  On the other hand, the
% bulk of packages and fonts are in TEXMFDIST, and locally-installed
% versions should take precedence over those -- although it is generally
% a source of confusion to have different versions of a package
% installed, whatever the trees, so try to avoid it.
TEXMF = {$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}

% Where to look for ls-R files.  There need not be an ls-R in the
% directories in this path, but if there is one, Kpathsea will use it.
% By default, this is only the !! elements of TEXMF, so that mktexlsr
% does not create ls-R files in the non-!! elements -- because if an
% ls-R is present, it will be used, and the disk will not be searched.
% This is arguably a bug in kpathsea.
TEXMFDBS = {!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}

It should be enough (I haven't tested it), to put the lines

TEXMF = {$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,$TEXMFLOCAL,!!$TEXMFDIST}
TEXMFDBS = {!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,$TEXMFLOCAL,!!$TEXMFDIST}

into the texmf.cnf returned by kpsewhich texmf.cnf, thus disabling database search in $TEXMFLOCAL.

Answer 2

Martin's answer looks like the correct answer to your question, but I'd like to answer the question you didn't ask, but should have asked IMHO :-) And that question is: how do I allow someone to maintain TEXMFLOCAL?

You seem to assume that only the admin can update the ls-R file in TEXMFLOCAL. That's not the case. Anyone who can write to TEXMFLOCAL can update the file. If your users have enough privilege to update (rename) files in TEXMFLOCAL, they should already be able to update the ls-R file there without any problem. Just tell them to run mktexlsr /path/to/texmflocal instead of just mktexlsr if they want to avoid errors concerning the trees in which they cannot write, otherwise they can just ignore errors, TEXMFLOCAL/ls-R will be updated anyway.

That's the simple answer to how to share TeX Live administration privileges: just use the filesystem permissions.

(PS: if you current ls-R file is owned by root, you'll need to chown or chgrp and chmod it the first time.)