Discussion:
[tex-live] $TEXMFHOME not working right
Joel C. Salomon
2010-05-14 03:44:05 UTC
Permalink
I have a net install of TL ?09 on my Ubuntu machine, installed for the
whole machine (so I run tlmgr under sudo). I?m trying to install some
packages in $TEXMFHOME, but they are not being found. Running mktexlsr,
either as root or not, does not update that tree, so I tried doing it
explicitly:

chesky at derrial:~$ mktexlsr --verbose `kpsewhich --expand-var='$TEXMFHOME'`
mktexlsr: Updating /home/chesky/texmf/ls-R...
mktexlsr: Done.

The ls-R file is created, but .sty files are still not found for
typesetting.

I looked for an option in tlmgr for $TEXMFHOME (I vaguely recall such an
option in the installer?) but could not find it.

Is there a configuration file to edit to fix this?

?Joel Salomon
Norbert Preining
2010-05-14 04:13:49 UTC
Permalink
Post by Joel C. Salomon
chesky at derrial:~$ mktexlsr --verbose `kpsewhich --expand-var='$TEXMFHOME'`
mktexlsr: Updating /home/chesky/texmf/ls-R...
mktexlsr: Done.
The ls-R file is created, but .sty files are still not found for
typesetting.
No need for that, or even counter-productive. TEXMFHOME is searched
for without ls-R files present.
Post by Joel C. Salomon
I looked for an option in tlmgr for $TEXMFHOME (I vaguely recall such an
option in the installer?) but could not find it.
Is there a configuration file to edit to fix this?
It shoujld work.

Can you send the output of
tlmgr conf
please?

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
VENTNOR (n.) One who, having been visited as a child by a mysterious
gypsy lady, is gifted with the strange power of being able to operate
the air-nozzles above aeroplane seats.
--- Douglas Adams, The Meaning of Liff
Joel C. Salomon
2010-05-14 11:28:20 UTC
Permalink
Post by Joel C. Salomon
I looked for an option in tlmgr for $TEXMFHOME (I vaguely recall such an
option in the installer?) but could not find it.
Is there a configuration file to edit to fix this?
TEXMFHOME is searched for without ls-R files present.
<snip>
It shoujld work.
Can you send the output of
tlmgr conf
please?
The relevant lines are:

======== version information =======
tlmgr revision 18011 (2010-04-26 21:41:33 +0200)
tlmgr using installation: /opt/texlive/2009
TeX Live (http://tug.org/texlive) version 2009
?
======== kpathsea variables ========
?
TEXMFHOME=/home/chesky/texmf
VARTEXFONTS=/home/chesky/.texlive2009/texmf-var/fonts
TEXMF={/home/chesky/.texlive2009/texmf-config,/home/chesky/.texlive2009/texmf-var,/home/chesky/texmf,!!/opt/texlive/2009/texmf-config,!!/opt/texlive/2009/texmf-var,!!/opt/texlive/2009/texmf,!!/opt/texlive/2009/../texmf-local,!!/opt/texlive/2009/texmf-dist}
SYSTEXMF=/opt/texlive/2009/texmf-var:/opt/texlive/2009/texmf:/opt/texlive/2009/../texmf-local:/opt/texlive/2009/texmf-dist
TEXMFDBS={!!/opt/texlive/2009/texmf-config,!!/opt/texlive/2009/texmf-var,!!/opt/texlive/2009/texmf,!!/opt/texlive/2009/../texmf-local,!!/opt/texlive/2009/texmf-dist}
?

I?ve attached the full output in case I missed something pertinent.

(BTW, it complained of ?missing finding of XDvi, config!?.)

I?m trying to play with the development versions of fontspec &c., so I
installed fontspec.sty [2010/05/14 v2.0 ?] (and the .cfg & .lua) in
/home/chesky/texmf/tex/latex/fontspec. I even get this result:

chesky at derrial:~$ kpsewhich -all fontspec.sty
/home/chesky/texmf/tex/latex/fontspec/fontspec.sty
/opt/texlive/2009/texmf-dist/tex/xelatex/fontspec/fontspec.sty
chesky at derrial:~$ kpsewhich fontspec.sty
/home/chesky/texmf/tex/latex/fontspec/fontspec.sty

But when I try to typeset the documentation for the development version
of xltxtra, I get:

chesky at derrial:~/Downloads/wspr/xltxtra$ xelatex xltxtra.dtx
This is XeTeX, Version 3.1415926-2.2-0.9995.2 (TeX Live 2009)
?
LaTeX Warning: You have requested, on input line 28, version
`2010/05/14 v2.0' of package fontspec,
but only version
`2008/08/09 v1.18 Advanced font selection for XeLaTeX'
is available.
?

Why is the system not preferring my locally-installed version?

?Joel Salomon
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tlmgr conf
URL: <http://tug.org/pipermail/tex-live/attachments/20100514/f1514264/attachment.pl>
George N. White III
2010-05-14 11:51:07 UTC
Permalink
Post by Joel C. Salomon
Post by Joel C. Salomon
I looked for an option in tlmgr for $TEXMFHOME (I vaguely recall such an
option in the installer?) but could not find it.
Is there a configuration file to edit to fix this?
TEXMFHOME is searched for without ls-R files present.
<snip>
It shoujld work.
Can you send the output of
? ? ? tlmgr conf
please?
======== version information =======
tlmgr revision 18011 (2010-04-26 21:41:33 +0200)
tlmgr using installation: /opt/texlive/2009
TeX Live (http://tug.org/texlive) version 2009
?
======== kpathsea variables ========
?
TEXMFHOME=/home/chesky/texmf
VARTEXFONTS=/home/chesky/.texlive2009/texmf-var/fonts
TEXMF={/home/chesky/.texlive2009/texmf-config,/home/chesky/.texlive2009/texmf-var,/home/chesky/texmf,!!/opt/texlive/2009/texmf-config,!!/opt/texlive/2009/texmf-var,!!/opt/texlive/2009/texmf,!!/opt/texlive/2009/../texmf-local,!!/opt/texlive/2009/texmf-dist}
SYSTEXMF=/opt/texlive/2009/texmf-var:/opt/texlive/2009/texmf:/opt/texlive/2009/../texmf-local:/opt/texlive/2009/texmf-dist
TEXMFDBS={!!/opt/texlive/2009/texmf-config,!!/opt/texlive/2009/texmf-var,!!/opt/texlive/2009/texmf,!!/opt/texlive/2009/../texmf-local,!!/opt/texlive/2009/texmf-dist}
?
I?ve attached the full output in case I missed something pertinent.
(BTW, it complained of ?missing finding of XDvi, config!?.)
I?m trying to play with the development versions of fontspec &c., so I
installed fontspec.sty [2010/05/14 v2.0 ?] (and the .cfg & .lua) in
chesky at derrial:~$ kpsewhich -all fontspec.sty
/home/chesky/texmf/tex/latex/fontspec/fontspec.sty
/opt/texlive/2009/texmf-dist/tex/xelatex/fontspec/fontspec.sty
chesky at derrial:~$ kpsewhich fontspec.sty
/home/chesky/texmf/tex/latex/fontspec/fontspec.sty
But when I try to typeset the documentation for the development version
chesky at derrial:~/Downloads/wspr/xltxtra$ xelatex xltxtra.dtx
This is XeTeX, Version 3.1415926-2.2-0.9995.2 (TeX Live 2009)
?
LaTeX Warning: You have requested, on input line 28, version
? ? ? ? ? ? ? `2010/05/14 v2.0' of package fontspec,
? ? ? ? ? ? ? but only version
? ? ? ? ? ? ? `2008/08/09 v1.18 Advanced font selection for XeLaTeX'
? ? ? ? ? ? ? is available.
?
Why is the system not preferring my locally-installed version?
?Joel Salomon
Because when running xelatex, the xelatex paths are searched first
(here I have duplicated your HOMETEXMF layout):

$ kpsewhich -all fontspec.sty
/Users/gwhite/Library/texmf/tex/latex/fontspec/fontspec.sty
/usr/local/texlive/2009/texmf-dist/tex/xelatex/fontspec/fontspec.sty
$ kpsewhich fontspec.sty
/Users/gwhite/Library/texmf/tex/latex/fontspec/fontspec.sty

but, if you tell kpsewhich to search for xelatex thingies:

$ kpsewhich -progname=xelatex fontspec.sty
/usr/local/texlive/2009/texmf-dist/tex/xelatex/fontspec/fontspec.sty

When adding updated versions of files that exist under texmf-dist, the
general rule is to copy the same directory structure, so you should
be using "/home/chesky/texmf/tex/xelatex/fontspec/fontspec.sty".
--
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
Manuel Pégourié-Gonnard
2010-05-14 12:01:01 UTC
Permalink
Post by George N. White III
Because when running xelatex, the xelatex paths are searched first
$ kpsewhich -all fontspec.sty
/Users/gwhite/Library/texmf/tex/latex/fontspec/fontspec.sty
/usr/local/texlive/2009/texmf-dist/tex/xelatex/fontspec/fontspec.sty
$ kpsewhich fontspec.sty
/Users/gwhite/Library/texmf/tex/latex/fontspec/fontspec.sty
$ kpsewhich -progname=xelatex fontspec.sty
/usr/local/texlive/2009/texmf-dist/tex/xelatex/fontspec/fontspec.sty
When adding updated versions of files that exist under texmf-dist, the
general rule is to copy the same directory structure, so you should
be using "/home/chesky/texmf/tex/xelatex/fontspec/fontspec.sty".
By the way, it is in principle correct to install the newest version of fontspec
in tex/latex, since it works with both xelatex and lualatex. In my personal
setup, that's what I'm doing, and I made a symlink in tex/xelatex:

mpg at roth:~/texmf/tex/xelatex% ls -l fontspec
lrwxrwxrwx 1 mpg mpg 17 avril 10 14:30 fontspec -> ../latex/fontspec

to work around this problem.

Manuel.
Vladimir Lomov
2010-05-14 04:58:56 UTC
Permalink
Post by Joel C. Salomon
I have a net install of TL ?09 on my Ubuntu machine, installed for the
whole machine (so I run tlmgr under sudo). I?m trying to install some
packages in $TEXMFHOME, but they are not being found. Running mktexlsr,
either as root or not, does not update that tree, so I tried doing it
chesky at derrial:~$ mktexlsr --verbose `kpsewhich --expand-var='$TEXMFHOME'`
mktexlsr: Updating /home/chesky/texmf/ls-R...
mktexlsr: Done.
The ls-R file is created, but .sty files are still not found for
typesetting.
What
$ kpsewhich YOURSTYLEFILE.sty
returns?
Post by Joel C. Salomon
I looked for an option in tlmgr for $TEXMFHOME (I vaguely recall such an
option in the installer?) but could not find it.
Is there a configuration file to edit to fix this?
Please keep in mind that TeX Live is TDS compliant distro.

Suppose you have 'my-priv.sty' package. You should place it here:
$HOME/texmf/tex/latex/chesky/
^^^^^^
(any sensible name is ok)

After that if you run
$ kpsewhich my-priv.sty
you should get
$HOME/texmf/tex/latex/chesky/my-priv.sty
($HOME will be expanded)
--
Is death legally binding?
Robin Fairbairns
2010-05-14 07:25:50 UTC
Permalink
Post by Norbert Preining
Post by Joel C. Salomon
chesky at derrial:~$ mktexlsr --verbose `kpsewhich --expand-var='$TEXMFHOME'`
mktexlsr: Updating /home/chesky/texmf/ls-R...
mktexlsr: Done.
The ls-R file is created, but .sty files are still not found for
typesetting.
No need for that, or even counter-productive. TEXMFHOME is searched
for without ls-R files present.
indeed. however, if you access your home directory over nfs (as *all*
my users at work do) it has the potential to seriously slow things
down. scanning directories over nfs this way is regularly the source of
support calls about "tex suddenly slow" (after loading something like pgf).
Post by Norbert Preining
Post by Joel C. Salomon
I looked for an option in tlmgr for $TEXMFHOME (I vaguely recall such an
option in the installer?) but could not find it.
Is there a configuration file to edit to fix this?
It shoujld work.
Can you send the output of
tlmgr conf
please?
another possibility is non-tds layout in texmfhome. i've had some of
those too.

robin
Reinhard Kotucha
2010-05-15 17:06:02 UTC
Permalink
Post by Robin Fairbairns
Post by Norbert Preining
Post by Joel C. Salomon
chesky at derrial:~$ mktexlsr --verbose `kpsewhich --expand-var='$TEXMFHOME'`
mktexlsr: Updating /home/chesky/texmf/ls-R...
mktexlsr: Done.
The ls-R file is created, but .sty files are still not found for
typesetting.
No need for that, or even counter-productive. TEXMFHOME is searched
for without ls-R files present.
indeed. however, if you access your home directory over nfs (as
*all* my users at work do) it has the potential to seriously slow
things down. scanning directories over nfs this way is regularly
the source of support calls about "tex suddenly slow" (after
loading something like pgf).
Ideally there are only very few files in TEXMFHOME because TeX Live is
very complete. However, the situation might be different if users
want to use beta versions of huge packages. And installing user
specific files locally is quite unfortunate if HOME is on a server.

What you can do is to add TEXMFHOME to TEXMFDBS. This has no effect
and files are still searched in the file system, at least until a user
runs texhash. Then he has to keep the ls-R file up-to-date or remove
it.

One can't assume that even without TEXMFHOME in TEXMFDBS there will
never be an ls-R file in TEXMFHOME. There will always be one after
running getnonfreefonts. This is not actually desired and I wasn't
even aware of until now. The reason is that texhash ignores TEXMFDBS
if it's called with an argument. I didn't even know that this works
at all:

$ texhash /usr/local/share/emacs
texhash: Updating /usr/local/share/emacs/ls-R...
texhash: Done.

getnonfreefonts[-sys] calls texhash with an argument in order to avoid
creating texmf-dist/ls-R each time because this consumes a lot of time
and getnonfreefonts[-sys] already knows where it installed the fonts.

The behaviour of texhash is a bit unfortunate. It would be better to
obey TEXMFDBS always and add a --force option which allows for
creating ls-R files in arbitrary directories.

Anyway, TeX Live versions prior to TeX Live 2007 had:

TEXMFDBS = $TEXMF

Every user had to run texhash after adding files and nobody
complained. The setting of TEXMFDBS were changed due to a bug in
fmtutil. BTW, this bug was reported by Donald Knuth himself. We were
clueless but after I encountered the same problem, I proposed to
remove TEXMF[SYS]VAR from TEXMFDBS as a simple workaround. The
problem was that fmtutil appended newly created format files to ls-R
files without scanning the whole directory tree. This worked fine in
the past but with teTeX-3 it wasn't as reliable as before.

When I discussed the TEXMF[SYS]VAR issue with Karl, we also discussed
how to treat TEXMFHOME. We couldn't set "TEXMFDBS = $TEXMF" anymore
because we had to treat TEXMF[SYS]VAR as an exception anyway.

Regarding TEXMFHOME, we assumed that there will be only a few files
and it's not worthwhile to create an ls-R file in this directory.
We thought that removing TEXMFHOME from TEXMFDBS makes life easier.

However, nowadays I think that this was not a good decision. It seems
that creating a TDS compliant directory structure somtimes causes
problems but most users are aware of texhash already.

Therefore I wouldn't object if the old behaviour is restored.

Regards,
Reinhard
--
----------------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
Khaled Hosny
2010-05-15 18:39:23 UTC
Permalink
Post by Reinhard Kotucha
TEXMFDBS = $TEXMF
Every user had to run texhash after adding files and nobody
complained.
I certainly didn't complain, but it was a very frustrating experience
first time I started adding stuff to TEXMFHOME and tex still can not
find it, I'm very glad this have been "fixed".

Regards,
Khaled
--
Khaled Hosny
Arabic localiser and member of Arabeyes.org team
Free font developer
Manuel Pégourié-Gonnard
2010-05-15 19:49:05 UTC
Permalink
Post by Khaled Hosny
Post by Reinhard Kotucha
TEXMFDBS = $TEXMF
Every user had to run texhash after adding files and nobody
complained.
I certainly didn't complain, but it was a very frustrating experience
first time I started adding stuff to TEXMFHOME and tex still can not
find it, I'm very glad this have been "fixed".
+1. Life is easier now, in my experience.

Manuel.
Reinhard Kotucha
2010-05-16 02:49:12 UTC
Permalink
Post by Khaled Hosny
Post by Reinhard Kotucha
TEXMFDBS = $TEXMF
Every user had to run texhash after adding files and nobody
complained.
I certainly didn't complain, but it was a very frustrating experience
first time I started adding stuff to TEXMFHOME and tex still can not
find it, I'm very glad this have been "fixed".
Sure, this can happen. But if you didn't know that you have to run
texhash, how did you know where exactly you have to put your files?
You certainly have to read documentation if you want to install files
in TEXMFHOME. There is much more you can do wrong.

I don't think that a problem have been "fixed", as you said. Please
note that the current behavior causes other problems, as Robin
reported. If people have many files in TEXMFHOME the system slows
down significantly, especially because TEXMFHOME is the first tree to
be searched. Please don't forget that even if a file resides in
another tree, TEXMFHOME is searched though on the disc.

With other words: Even if your TeX input file doesn't need anything
from TEXMFHOME, the file system is scanned each time. This is quite
inefficient and IMO the idea of kpathsea is completely ignored.

Another issue is that if TEXMFHOME is treated as an exception, why not
treat TEXMFLOCAL as an exception too? Then the system becomes even
less efficient. But why should they be treated differently?

My opinion is that kpathsea is a good thing and should be used by
default. I dislike exceptions generally. The problem is that every
exception needs extra explanations and and blows up documentation.
It's better to avoid exceptions. The less we have have to explain,
the less people have to read. You can't install files without reading
the documentation anyway. It's a wrong conclusion that circumventing
kpathsea makes things easier. You still have to be familiar with TDS,
otherwise your files are not found reliably.

What we have now solves a tiny problem for people who didn't read the
documentation. They have to be in luck if their files are found at
all (if they didn't read any documentation), and the system is slow by
default. Is this really what we want?

Well, the short answer is: kpathsea is there, it's a good thing, and
should be used by default. No exceptions please, if avoidable. Users
should simply read documentation if the trial-and-error method fails.

Regards,
Reinhard
--
----------------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
Manuel Pégourié-Gonnard
2010-05-16 07:42:07 UTC
Permalink
Post by Reinhard Kotucha
Post by Khaled Hosny
I certainly didn't complain, but it was a very frustrating experience
first time I started adding stuff to TEXMFHOME and tex still can not
find it, I'm very glad this have been "fixed".
Sure, this can happen. But if you didn't know that you have to run
texhash, how did you know where exactly you have to put your files?
You certainly have to read documentation if you want to install files
in TEXMFHOME. There is much more you can do wrong.
Because you heard about it from a colleague or an incomplete documentation?

As a matter of personal experience, a few years ago, when I first tried to
install something in my TEXMFHOME, I did two mistakes:
- not running mktexlsr (it was TL05)
- not putting tex input files in a "tex" subdirectory
and I remember it took me a long time to understand.

Now, there's one less standard mistake to make. That's a Good Thing IMO.
Post by Reinhard Kotucha
What we have now solves a tiny problem for people who didn't read the
documentation. They have to be in luck if their files are found at
all (if they didn't read any documentation), and the system is slow by
default.
Well, it's slow only on nfs mounts with big texmfhome trees (which is not
exactly the most common case).
Post by Reinhard Kotucha
Is this really what we want?
Do we really want to engage now in a discussion about something that was already
decided three years ago?

Manuel.
Reinhard Kotucha
2010-05-16 23:20:54 UTC
Permalink
Post by Manuel Pégourié-Gonnard
Post by Reinhard Kotucha
Post by Khaled Hosny
I certainly didn't complain, but it was a very frustrating experience
first time I started adding stuff to TEXMFHOME and tex still can not
find it, I'm very glad this have been "fixed".
Sure, this can happen. But if you didn't know that you have to run
texhash, how did you know where exactly you have to put your files?
You certainly have to read documentation if you want to install files
in TEXMFHOME. There is much more you can do wrong.
Because you heard about it from a colleague or an incomplete documentation?
As a matter of personal experience, a few years ago, when I first tried to
- not running mktexlsr (it was TL05)
- not putting tex input files in a "tex" subdirectory
and I remember it took me a long time to understand.
Now, there's one less standard mistake to make. That's a Good Thing IMO.
Well, you still can do the same mistake if you install in TEXMFLOCAL.
And this is what most people do on their own machines.
Post by Manuel Pégourié-Gonnard
Post by Reinhard Kotucha
What we have now solves a tiny problem for people who didn't read
the documentation. They have to be in luck if their files are
found at all (if they didn't read any documentation), and the
system is slow by default.
Well, it's slow only on nfs mounts with big texmfhome trees (which
is not exactly the most common case).
Sure, the size matters. But the NFS issue Robin mentioned is by far
not the worst case. NFS is a bit slower than a local file system
because each time you access a file it has to check whether the copy
in the cache of the client is up-to-date.

Suppose that you have TEXMFHOME on a USB stick. On Linux I usually
mount the stick manually. Then all files are in the cache and I
actually don't notice that they are on a USB stick. If people are
using an automounter, I suppose that the cache is cleared if the
timeout is reached. Under Windows, files on a USB stick are not
cached at all. It's horribly slow.

Nevertheless, having TEXMFHOME on a USB stick makes sense.
Post by Manuel Pégourié-Gonnard
Post by Reinhard Kotucha
Is this really what we want?
Do we really want to engage now in a discussion about something
that was already decided three years ago?
As I said, I noticed yesterday that texhash creates an ls-R file when
it's called with an argument, regardless of the value of TEXMFDBS.
People who used getnonfreefonts in the past *have* an ls-R file in
TEXMFHOME already. BTW, I don't know how to solve this problem in
getnonfreefonts reasonably. And I don't know whether it's reasonable
at all not to use an ls-R file in this case.

If you run getnonfreefonts --all, you'll have about 100 directories in
TEXMFHOME which will be scanned each time. And in the near future
I'll add support for two new font packages which means that there will
be even much more directories soon.
Post by Manuel Pégourié-Gonnard
Now, there's one less standard mistake to make. [...]
You have to add the word "probably".

The current situation is:

* You have to run texhash if you install in TEXMFLOCAL.

* You don't have to run texhash if you install in TEXMFHOME, at
least unless there is an ls-R file already.

This is *very* confusing, IMO.

TeX Live is a huge system and if we want to keep it manageable, we
have to make things as consistent as possible. I'm convinced that
consistency is *much* more important than exceptions which make life a
little bit easier for people who didn't read the documentation.

And once there is an ls-R file in TEXMFHOME already, it's used by
kpathsea, but texhash won't update it because it's not in TEXMFDBS.
In order to update an existing ls-R file in TEXMFHOME you have to say

texhash `kpsewhich -var-value=TEXMFHOME`

Just running texhash without an argument isn't sufficient.

***PLEASE*** try to explain this to users.

The more I think about it, the more I'm convinced that removing
TEXMFHOME from TEXMFDBS was a *** VERY BAD *** idea. It causes more
problems than it solves.

It's better to add TEXMFHOME to TEXMFDBS in texmf.cnf again.
Everything will be easier then. Definitely.

Regards,
Reinhard
--
----------------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
Manuel Pégourié-Gonnard
2010-05-16 23:29:18 UTC
Permalink
Hi Reinhard,

I'm sorry, but I still disagree, and I don't feel like engaging in a lengthy
discussion about that now.

Manuel.
Post by Reinhard Kotucha
Post by Manuel Pégourié-Gonnard
Post by Reinhard Kotucha
Post by Khaled Hosny
I certainly didn't complain, but it was a very frustrating experience
first time I started adding stuff to TEXMFHOME and tex still can not
find it, I'm very glad this have been "fixed".
Sure, this can happen. But if you didn't know that you have to run
texhash, how did you know where exactly you have to put your files?
You certainly have to read documentation if you want to install files
in TEXMFHOME. There is much more you can do wrong.
Because you heard about it from a colleague or an incomplete documentation?
As a matter of personal experience, a few years ago, when I first tried to
- not running mktexlsr (it was TL05)
- not putting tex input files in a "tex" subdirectory
and I remember it took me a long time to understand.
Now, there's one less standard mistake to make. That's a Good Thing IMO.
Well, you still can do the same mistake if you install in TEXMFLOCAL.
And this is what most people do on their own machines.
Post by Manuel Pégourié-Gonnard
Post by Reinhard Kotucha
What we have now solves a tiny problem for people who didn't read
the documentation. They have to be in luck if their files are
found at all (if they didn't read any documentation), and the
system is slow by default.
Well, it's slow only on nfs mounts with big texmfhome trees (which
is not exactly the most common case).
Sure, the size matters. But the NFS issue Robin mentioned is by far
not the worst case. NFS is a bit slower than a local file system
because each time you access a file it has to check whether the copy
in the cache of the client is up-to-date.
Suppose that you have TEXMFHOME on a USB stick. On Linux I usually
mount the stick manually. Then all files are in the cache and I
actually don't notice that they are on a USB stick. If people are
using an automounter, I suppose that the cache is cleared if the
timeout is reached. Under Windows, files on a USB stick are not
cached at all. It's horribly slow.
Nevertheless, having TEXMFHOME on a USB stick makes sense.
Post by Manuel Pégourié-Gonnard
Post by Reinhard Kotucha
Is this really what we want?
Do we really want to engage now in a discussion about something
that was already decided three years ago?
As I said, I noticed yesterday that texhash creates an ls-R file when
it's called with an argument, regardless of the value of TEXMFDBS.
People who used getnonfreefonts in the past *have* an ls-R file in
TEXMFHOME already. BTW, I don't know how to solve this problem in
getnonfreefonts reasonably. And I don't know whether it's reasonable
at all not to use an ls-R file in this case.
If you run getnonfreefonts --all, you'll have about 100 directories in
TEXMFHOME which will be scanned each time. And in the near future
I'll add support for two new font packages which means that there will
be even much more directories soon.
Post by Manuel Pégourié-Gonnard
Now, there's one less standard mistake to make. [...]
You have to add the word "probably".
* You have to run texhash if you install in TEXMFLOCAL.
* You don't have to run texhash if you install in TEXMFHOME, at
least unless there is an ls-R file already.
This is *very* confusing, IMO.
TeX Live is a huge system and if we want to keep it manageable, we
have to make things as consistent as possible. I'm convinced that
consistency is *much* more important than exceptions which make life a
little bit easier for people who didn't read the documentation.
And once there is an ls-R file in TEXMFHOME already, it's used by
kpathsea, but texhash won't update it because it's not in TEXMFDBS.
In order to update an existing ls-R file in TEXMFHOME you have to say
texhash `kpsewhich -var-value=TEXMFHOME`
Just running texhash without an argument isn't sufficient.
***PLEASE*** try to explain this to users.
The more I think about it, the more I'm convinced that removing
TEXMFHOME from TEXMFDBS was a *** VERY BAD *** idea. It causes more
problems than it solves.
It's better to add TEXMFHOME to TEXMFDBS in texmf.cnf again.
Everything will be easier then. Definitely.
Regards,
Reinhard
Reinhard Kotucha
2010-05-17 00:27:15 UTC
Permalink
Post by Manuel Pégourié-Gonnard
Hi Reinhard,
I'm sorry, but I still disagree, and I don't feel like engaging in
a lengthy discussion about that now.
Did you read my previous mail at all???????

Yeah, let's add TEXMFHOME to TEXMFDBS again. This solves many
problems. Do you think that *I'm* interested in endless discussions?

What we have now is wrong. Definitely. Period.

Regards,
Reinhard
--
----------------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
Manuel Pégourié-Gonnard
2010-05-17 08:48:54 UTC
Permalink
Post by Reinhard Kotucha
Post by Manuel Pégourié-Gonnard
I'm sorry, but I still disagree, and I don't feel like engaging in
a lengthy discussion about that now.
Did you read my previous mail at all???????
I did. That was the purpose (obviously missed) of my reply: let you know that I
read your mail.
Post by Reinhard Kotucha
Yeah, let's add TEXMFHOME to TEXMFDBS again. This solves many
problems.
It would re-introduce other problems. You probably think the problems it would
solve are greater than the problems it would introduce, apparently we don't
weight problems the same way.
Post by Reinhard Kotucha
Do you think that *I'm* interested in endless discussions?
Not at all, I never said that. Your points are interesting and would deserve a
detailed reply, I just don't feel like discuss it at this point.

I see no urging reason to change (or even discuss about changing) a setting that
has been there for 3 years without creating numerous complains, right now.
Post by Reinhard Kotucha
What we have now is wrong. Definitely. Period.
That's your opinion.

Manuel.
Joel C. Salomon
2010-05-17 22:45:01 UTC
Permalink
Post by Manuel Pégourié-Gonnard
Post by Reinhard Kotucha
Yeah, let's add TEXMFHOME to TEXMFDBS again. This solves many
problems.
It would re-introduce other problems. You probably think the problems it would
solve are greater than the problems it would introduce, apparently we don't
weight problems the same way.
<snip>
Post by Manuel Pégourié-Gonnard
I see no urging reason to change (or even discuss about changing) a setting that
has been there for 3 years without creating numerous complains, right now.
As the OP on this thread, may I weigh in with my $0.02?

I?d like a choice. If I often add or change things in TEXMFHOME, having
to recreate ls-R every time becomes a pain. If my home directory is
across the network, having ls-R becomes a tremendous time-saver. So?
just tell me that.

On my home system, I?ll very gladly do without ls-R in TEXMFHOME. On my
portable flash drive installation, and when I administer a network, I
now know to add TEXMFHOME to TEXMFDBS. As for what the default should
be, perhaps ?all true believers shall break their eggs at the convenient
end?.

?Joel Salomon
Manuel Pégourié-Gonnard
2010-05-18 06:55:31 UTC
Permalink
Post by Joel C. Salomon
As the OP on this thread, may I weigh in with my $0.02?
Sure.
Post by Joel C. Salomon
I?d like a choice.
You do have a choice (as for almost everything in TL, may I add). Just run
"mktexlsr ~/texmf" (assuming a standard location of TEXMFHOME) everytime you
change files in TEXMFHOME if you want a ls-R file here. Just don't do that (and
delete any ls-R mistakenly created) if don't want.

(Alternatively, if you want to have a ls-R here, set TEXMFDBS to include
TEXMFHOME in your local texmf.cnf, then running mktexlsr without argument will
include TEXMFHOME too.)

Manuel.
Joel C. Salomon
2010-05-18 11:49:32 UTC
Permalink
Post by Manuel Pégourié-Gonnard
You do have a choice (as for almost everything in TL, may I add). Just run
"mktexlsr ~/texmf" (assuming a standard location of TEXMFHOME) everytime you
change files in TEXMFHOME if you want a ls-R file here. Just don't do that (and
delete any ls-R mistakenly created) if don't want.
(Alternatively, if you want to have a ls-R here, set TEXMFDBS to include
TEXMFHOME in your local texmf.cnf, then running mktexlsr without argument will
include TEXMFHOME too.)
In other words, the ?convenient end? solution. Terrific.

?Joel Salomon
George N. White III
2010-05-18 12:06:06 UTC
Permalink
Post by Joel C. Salomon
Post by Manuel Pégourié-Gonnard
Yeah, let's add TEXMFHOME to TEXMFDBS again. ?This solves many
problems.
It would re-introduce other problems. You probably think the problems it would
solve are greater than the problems it would introduce, apparently we don't
weight problems the same way.
<snip>
Post by Manuel Pégourié-Gonnard
I see no urging reason to change (or even discuss about changing) a setting that
has been there for 3 years without creating numerous complains, right now.
As the OP on this thread, may I weigh in with my $0.02?
I?d like a choice. ?If I often add or change things in TEXMFHOME, having
to recreate ls-R every time becomes a pain. ?If my home directory is
across the network, having ls-R becomes a tremendous time-saver. ?So?
just tell me that.
On my home system, I?ll very gladly do without ls-R in TEXMFHOME. ?On my
portable flash drive installation, and when I administer a network, I
now know to add TEXMFHOME to TEXMFDBS. ?As for what the default should
be, perhaps ?all true believers shall break their eggs at the convenient
end?.
This just confirms that there are some things (other than papersize!) were any
choice of a "default" configuration will create problems for some users (or the
local "guru" who gets the complaints about TeX being slow for users with NFS
home directories or printers rejecting jobs for requesting a paper size not
found in any tray).

TL is a large, complex system with very diverse users, so users need to
understand that some effort is often needed to tweak their configuration.
A few of the choices (paper size, symbolic links in /usr/bin) are so important
that they get special mention in the installation tool. It might be
helpful to
have a short document on "commonly applied tweaks" (CAT) that can be done
without removing and installing the whole system (as if it was a
Windows package):

1. conflicts with default output settings

-- papersize settings other than the system default for one
document or project or user

-- switching between CM and LM fonts

2. performance tweaks:

-- settings for NFS mounted home directories or large TEXMFHOME trees

3. coexisting with package managers in linux

-- dummy packages

4. reversing install-time choices

-- removing symbolic links: how to ensure that 3rd party tools can
still find the programs

-- changing ownership
--
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
Robin Fairbairns
2010-05-14 11:41:06 UTC
Permalink
Post by Joel C. Salomon
Post by Joel C. Salomon
I looked for an option in tlmgr for $TEXMFHOME (I vaguely recall such an
option in the installer?) but could not find it.
Is there a configuration file to edit to fix this?
TEXMFHOME is searched for without ls-R files present.
<snip>
It shoujld work.
[...]
Post by Joel C. Salomon
I?m trying to play with the development versions of fontspec &c., so I
installed fontspec.sty [2010/05/14 v2.0 ?] (and the .cfg & .lua) in
chesky at derrial:~$ kpsewhich -all fontspec.sty
/home/chesky/texmf/tex/latex/fontspec/fontspec.sty
/opt/texlive/2009/texmf-dist/tex/xelatex/fontspec/fontspec.sty
chesky at derrial:~$ kpsewhich fontspec.sty
/home/chesky/texmf/tex/latex/fontspec/fontspec.sty
But when I try to typeset the documentation for the development version
chesky at derrial:~/Downloads/wspr/xltxtra$ xelatex xltxtra.dtx
This is XeTeX, Version 3.1415926-2.2-0.9995.2 (TeX Live 2009)
?
LaTeX Warning: You have requested, on input line 28, version
`2010/05/14 v2.0' of package fontspec,
but only version
`2008/08/09 v1.18 Advanced font selection for XeLaTeX'
is available.
?
Why is the system not preferring my locally-installed version?
because it's looking at the tex/xelatex tree, and you've put it on
tex/latex
Joel C. Salomon
2010-05-14 12:00:21 UTC
Permalink
Post by Robin Fairbairns
Post by Joel C. Salomon
Why is the system not preferring my locally-installed version?
because it's looking at the tex/xelatex tree, and you've put it on
tex/latex
Thanks; that fixed it.

?Joel Salomon
Robin Fairbairns
2010-05-16 23:36:37 UTC
Permalink
Post by Reinhard Kotucha
Sure, the size matters. But the NFS issue Robin mentioned is by far
not the worst case. NFS is a bit slower than a local file system
because each time you access a file it has to check whether the copy
in the cache of the client is up-to-date.
the problem isn't file reading, it's searching for files. nfs is *far*
slower to scan a directory than is a local disc; hence i only get the
reports when someone has loaded a large package into their ~/texmf

(in our environment, where everything on $HOME is agressively backed up
in our array of netapp filers, such behaviour is pretty undesirable,
since i already have ctan in the same array. telling the users that is
mare difficult than you would believe. they're _supposed_ to be
computer scientists...)
Post by Reinhard Kotucha
Suppose that you have TEXMFHOME on a USB stick. On Linux I usually
mount the stick manually. Then all files are in the cache and I
actually don't notice that they are on a USB stick. If people are
using an automounter, I suppose that the cache is cleared if the
timeout is reached. Under Windows, files on a USB stick are not
cached at all. It's horribly slow.
ouch.
Post by Reinhard Kotucha
Nevertheless, having TEXMFHOME on a USB stick makes sense.
of course. note that i merely explain why _i_ recommend it for the
environment here.

and then there's the fun to be had, regularly, with the texmfhome copy
of a now-obsolete version of a package.
Loading...