# Why is the wrong version of a package being loaded?

I was trying out Will Robertson's answer to this question and couldn't get it to compile correctly. Chasing through the log output, it seems that an old version of a package is getting loaded instead of a new one.

In slightly more detail, the package I was trying to test (unicode-math) said that it needed the most up-to-date versions of a couple of packages (the crucial one here seems to be fontspec). So, I downloaded them and put them in to my user texmf tree. However, when I compile the test file, the system one is loaded. This is despite the fact that the requesting file specifies a version later than that provided for by the system version, and the fact that when I do

kpsewhich fontspec.sty

then my version is returned.

MWE:

TeX Live 2009 (TeX Live 2010 has the right versions of the packages, but 2009 is what comes with my distribution) with unicode-math, fontspec, expl3, and xpackages from CTAN (as per the page on unicode-math).

test.tex:

\documentclass{article}
\usepackage{unicode-math}
\begin{document}
\end{document}


both

xelatex test.tex
lualatex test.tex


complain. The complaint appears later when loading some fonts, but given that the wrong fontspec package is loaded, I'm guessing that the error lies there rather than when TeX actually complains. To confirm locations:

tmp% kpsewhich fontspec.sty
/home/astacey/texmf/tex/latex/bzr/unmodified/fontspec/fontspec.sty


But the output from TeX (slightly condensed):

tmp% xelatex test.tex
This is XeTeX, Version 3.1415926-2.2-0.9995.2 (TeX Live 2009/Debian)
restricted \write18 enabled.
entering extended mode
(./test.tex
...
(/home/astacey/texmf/tex/latex/bzr/unmodified/unicode-math/unicode-math.sty
...
(/home/astacey/texmf/tex/latex/bzr/unmodified/xpackages/xparse.sty)
(/home/astacey/texmf/tex/latex/bzr/unmodified/xpackages/l3keys2e.sty)
(/usr/share/texmf-texlive/tex/xelatex/fontspec/fontspec.sty
...


Note that some packages are getting pulled from my local texmf tree, it's just this one that isn't.

-
What happens if you manually add \usepackage{fontspec} and specify the new version (see tug.org/docs/html/eplain/The-_005cusepackage-command.html) – Caramdir Jul 30 '10 at 11:38

Turned out that the answer to this one was that the different programs pass different options to the kpathsea engine about where to look for their packages. Since I was calling xelatex, packages in places like texmf/tex/xelatex were preferred over packages elsewhere in the texmf tree. When I ran kpsewhich on the command-line, it didn't know that I intended using xelatex so just looked everywhere. Moving the fontspec package to a directory under ~/texmf/tex/xelatex fixed that problem.

I see also that kpsewhich can be given the option '-engine X' to make its search engine-specific.

(Note: this program-specific behaviour seems to override the selection-by-date mechanism that Caramdir mentions in the comment to the question.

Also, that didn't solve everything as I'm now getting issues with font generation; I'm currently downloading TL2010 to see if that fixes everything in one fell swoop.)

-
That observation was very helpful when I tried to get the XITS fonts to work. – Caramdir Jul 31 '10 at 17:17

This is somewhat LaTeX distribution dependent, but as it happens, I am also using a version of TeXLive. (2007, as I've let a few upgrades to my distro go by.)

It isn't enough for package files to be in your local or user texmf-tree. You must also, as it were, register them with TeXLive. From a command prompt, run texhash. (On ubuntu, I seem to recall that this requires root privileges, so sudo texhash would be what you need.)

Provided TeXLive is aware that your user texmf-tree exists, running this command should cause it to scan that tree, amongst other places, and become aware of what packages it can find there.

If this doesn't work, then TeXLive needs to be made aware of your user texmf-tree. (How to set that up is, I think, a separate question.) Or, you could run sudo texhash path_to_user_texmf. But, since you say that some packages in your user tree do get invoked, this is an issue that you've already got sorted, it would seem.

-
Oh, of course. This is probably the cause of the problem. (?) – Will Robertson Jul 30 '10 at 14:26
Not guilty, yer honour. I did run texhash (well, actually mktexlsr ., but my system says that they are symlinks) and, as you'll note, some of my stuff gets pulled in. Actually, the problem is more subtle ... – Loop Space Jul 30 '10 at 15:18
But I think that this is a very useful answer to have after this question as it's something that can easily be forgotten. – Loop Space Jul 30 '10 at 15:27
@Andrew: I did note that some of your tree got used. That's compatible with my answer---it would occur if the unpulled package was added after the last hashing. But, since you've run the hashing command, well, we're above my pay-grade. – vanden Jul 30 '10 at 15:27
Good point. I missed that subtlety in your answer (though I had run it after installing the packages). – Loop Space Jul 30 '10 at 15:36

This is weird... if kpsewhich is returning the correct path for fontspec, I can't imagine why it's not being loaded. Perhaps try moving the old version of the package completely out of the texmf tree so only the new one is present?

TL2010 will be available soon (it's already available here now but it's in the process of being burnt to DVD for official release), hopefully mitigating this problem.

-
I've been busy downloading TL2010 otherwise I'd've been back to give a status report on this one ... – Loop Space Jul 30 '10 at 15:19