Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1293148

Summary:	texlive-2014 searches through ~/.texlive2013/ subdirectories instead of ~/.texlive2014/
Product:	[Fedora] Fedora	Reporter:	Michal Jaegermann <michal.jnn>
Component:	texlive	Assignee:	Tom "spot" Callaway <tcallawa>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	novyjindrich, tcallawa, than
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	texlive-2014-18.20140525_r34255.fc23	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-24 03:31:56 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michal Jaegermann 2015-12-20 18:47:33 UTC

Description of problem:

Looking at an output of 'kpsewhich -show-path=tex' I am finding now that subdirectories of ~/.texlive2013 are included in search while .texlive2014 would be expected (luatex, for example, wrote a while ago its cache into subdirectories of ~/.texlive2014/texmf-var/luatex-cache/).  It turns out that the current /usr/share/texlive/texmf-dist/web2c/texmf.cnf has these lines:

TEXMFVAR = ~/.texlive2013/texmf-var
TEXMFCONFIG = ~/.texlive2013/texmf-config

Moreover comments refer to "/some/path/to/texlive/2013/" as well.  That does not look as correct and intended.

Version-Release number of selected component (if applicable):
texlive-2014-16.20140525_r34255.fc23

Additional info:
On rawhide I see ~/.texlive2015/.... not that surprisingly.

Comment 1 Tom "spot" Callaway 2016-01-18 21:33:16 UTC

I'm going to fix this in the texmf.cnf, but that file is marked as %config, so it won't get overwritten for a lot of people. Will fix new installs though, its the best I can do. As you noted, rawhide is correct, so this should go away for good when Fedora 23 is EOL (except for people dist upgrading...).

Comment 2 Michal Jaegermann 2016-01-18 22:08:59 UTC

(In reply to Tom "spot" Callaway from comment #1)
> I'm going to fix this in the texmf.cnf, but that file is marked as %config,
> so it won't get overwritten for a lot of people.

It was using at some point in time ~/.texlive2014 (and I have traces of an evidence of that; unless this was from an F21 installation which got upgraded, ...hm).  Somehow texmf.cnf got overwritten and I am not sure now how this happened.

Comment 3 Fedora Update System 2016-01-20 03:16:12 UTC

texlive-2014-18.20140525_r34255.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-74f2c23353

Comment 4 Fedora Update System 2016-01-20 23:57:33 UTC

texlive-2014-18.20140525_r34255.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-74f2c23353

Comment 5 Fedora Update System 2016-01-24 03:31:38 UTC

texlive-2014-18.20140525_r34255.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 6 Michal Jaegermann 2016-01-24 22:45:41 UTC

(In reply to Tom "spot" Callaway from comment #1)
> I'm going to fix this in the texmf.cnf, but that file is marked as %config,
> so it won't get overwritten for a lot of people.

It surely got overwritten on an update for me and now I see again "2014". :-) That file was not modified from a distribution one so .rpmnew was not created.  It looks that ~/.texlive2014/ directories were at some point flipped back in this way to ~/.texlive2013/ in the first place.  Those who change texmf.cnf hopefully know what they are doing.