TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


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


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.

share|improve this question

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.

% 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.

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


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

share|improve this answer
A couple of issues with this: 1) The texmf.cnf file listed is texlive/2011/texmf.cnf, which I believe will be clobbered when the distribution is updated, 2) it breaks the documented behaviour of the texlive distribution that TEXMFLOCAL requires ls-R. I want to minimize the impact and mystery for future sys-admins who may not be TeX-savy. Is there some way of adding another tree that does not break behaviour and will be persistent between texlive updates? – mforbes Feb 24 '12 at 9:00
texlive/2011/texmf.cnf will not be clobbered when you stay with TL11; since there is currently no supported way to upgrade a TL installation (TL11 -> TL12), you will have to move it manually to texlive/2012/texmf.cnf. If you want to manage a separate texmf-Tree, see this discussion. – Martin Schröder Feb 24 '12 at 11:37

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.)

share|improve this answer
In principle this is a reasonable solution, but it requires the admins to create a separate group for just those users managing the packages (extra ongoing work for the sys-admins) and giving them the potential to "bring down the system" by messing up other packages if they leave the ls-R file in an incorrect state. For this reason, broadening the permissions of the ls-R file are not considered acceptable. (I am not the admin here, but a user trying to find as stable a solution as possible.) – mforbes Feb 24 '12 at 9:07
@mforbes: IMHO, the right solution (tm) to your problem is to let users maintain their packages, each package in a separate location (independent of TEXMFLOCAL, and preferably under SVN or similar), and then let the admin run a cron job that syncs TEXMFLOCAL with these locations and runs mktexlsr $TEXMFLOCAL afterwards. – Tomek Feb 26 '12 at 10:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.