Bug 864875

see also bug #855298, which previously reported the preview.sty problem.

*** Bug 855298 has been marked as a duplicate of this bug. ***

*** Bug 867656 has been marked as a duplicate of this bug. ***

texlive-2012-3.20121019_r28030.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/texlive-2012-3.20121019_r28030.fc18

(In reply to comment #0)

> 
> And finally, here is a workaround (in my experience running texhash was not
> necessary).

Such workaround does not really work.  See bug #868556 for bad sideffects.
Just running texhash clearly cannot work without expanding a kpathsea search
path in a configuration while dropping an extra link, even inside of
/usr/share/texlive/texmf-local/ would hack around the issue.

And what about a situation when you want to add some system-wide but local
packages?  Abusing directory descibed by TEXMFLOCAL looks like an awfull idea
even if old value for that looked actually saner if you wanted to be sure
that system updates will not clobber your changes/additions.

Package texlive-2012-3.20121019_r28030.fc18, PyX-0.11.1-4.fc18, evince-3.6.1-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing texlive-2012-3.20121019_r28030.fc18 PyX-0.11.1-4.fc18 evince-3.6.1-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16563/PyX-0.11.1-4.fc18,evince-3.6.1-2.fc18,texlive-2012-3.20121019_r28030.fc18
then log in and leave karma (feedback).

Ahh!  My suggestion (actually Jose's) of symlinking was a quick *work-around* for users who wanted to be able to compile their documents while waiting for a real fix.

I certainly wasn't suggesting this symlink be the official solution...  Probably there is another way to get "/usr/share/texmf" in the path.

(In reply to comment #7)
> Ahh!  My suggestion (actually Jose's) of symlinking was a quick
> *work-around* for users who wanted to be able to compile their documents
> while waiting for a real fix.

You are right, it was a quick hack to solve the problem while waiting for a better solution.

I suspect that the right place to change this is the file
/usr/share/texlive/texmf/web2c/texmf.cnf

where TEXMF is set.

(In reply to comment #8)
> (In reply to comment #7)
> > Ahh!  My suggestion (actually Jose's) of symlinking was a quick
> > *work-around* for users who wanted to be able to compile their documents
> > while waiting for a real fix.
> 
> You are right, it was a quick hack to solve the problem while waiting for a
> better solution.
> 
> I suspect that the right place to change this is the file
> /usr/share/texlive/texmf/web2c/texmf.cnf
> 
> where TEXMF is set.

Yup, but there is a problem that if TEXMFLOCAL is set directly to /usr/share/texmf then /usr/share/texlive/texmf-local won't be visible to kpathsea.

My proposal is to leave TEXMFLOCAL alone.

The question then comes why don't we have TEXMFMAIN as

TEXMFMAIN = $TEXMFROOT/../texmf

Does TEXMFMAIN needs to live in /usr/share/texlive/?

If it does then another possibility is

TEXMFMAIN = $TEXMFROOT/{texmf,../texmf}

but I am speculating on the last one, I did not test it.

To add further to the above debian has TEXMFMAIN as /usr/share/texmf

As can be seen going from
http://www.tug.org/texlive/debian.html

with the rules in

http://people.debian.org/~preining/TeX/Debian-TeX-Policy/ch5.html#s-tds-libkpse

I agree with the rationale there.

The role of the trees TEXMFMAIN and TEXMFDIST in Debian differ from upstream's original usage. Upstream uses TEXMFMAIN for the files that have to match the binary executables and TEXMFDIST for other TeX input files that are replaced when a new texmf tarball appears; this distinction is not necessary on a system with a decent package managment system. Instead, the basic TeX packages install their files into their TEXMFDIST directories [2] , while TEXMFMAIN is used by TeX add-on packages for their files and allows them to shadow older versions provided by the basic TeX packages. A couple of files from the basic TeX packages still need to be placed in TEXMFMAIN [3].

FWIW also I have never installed debian. :-)

(In reply to comment #9)

> 
> Yup, but there is a problem that if TEXMFLOCAL is set directly to
> /usr/share/texmf then /usr/share/texlive/texmf-local won't be visible to
> kpathsea.

I fail to see anything which would stop you from, say, putting a link to
/usr/share/texmf _inside_ a directory designated as TEXMFLOCAL.  Searches are here recursive or at least can be made that way.  Another obvious option would be to expand a default TEXMF value in texmf.cnf by adding to it another tree (in this particular case /usr/share/texmf).  Of course each and every user can do that for her/himself, and a comment at the top of texmf.cnf says exactly how to perform "private" modifications,  but it would seem to me that good defaults would be preferable.

Assuming that all stuff from /usr/share/texmf/ will eventually migrate to new locations (which may take quite a while) you may be left then with a "dead" symlink somewhere in /usr/share/texlive/ tree. In that sense expanding a default TEXMF, possibly indirectly through one of its components, looks like a safer possibility.

texlive-2012-3.20121019_r28030.fc18, PyX-0.11.1-4.fc18, evince-3.6.1-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.