Bug 868556

Summary:	texlive-base-2012 made "non-updatable" by a misguided symlink
Product:	[Fedora] Fedora	Reporter:	Michal Jaegermann <michal>
Component:	texlive	Assignee:	Jindrich Novy <jnovy>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	cbm, jnovy, pertusus, pknirsch
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-21 03:17:55 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 2012-10-20 19:42:21 UTC

Description of problem:

'yum update texlive-base' produces the following:

Running Transaction
  Updating   : 1:texlive-base-2012-3.20121019_r28030.fc19.noarch            1/2 
Error unpacking rpm package 1:texlive-base-2012-3.20121019_r28030.fc19.noarch
error: unpacking of archive failed on file /usr/share/texlive/texmf-local: cpio: rename
  Verifying  : 1:texlive-base-2012-3.20121019_r28030.fc19.noarch            1/2 
1:texlive-base-2012-3.20120926_r27815.fc19.noarch was supposed to be removed but is not!
  Verifying  : 1:texlive-base-2012-3.20120926_r27815.fc19.noarch            2/2 

Failed:
  texlive-base.noarch 1:2012-3.20120926_r27815.fc19                             
  texlive-base.noarch 1:2012-3.20121019_r28030.fc19              

The reason for that is that this update attempts to replace 'texmf-local'
by a symlink /usr/share/texlive/texmf-local -> ../texmf while previously this was a directory.

This is bound to fail as rpm will not do such operation without removing original texmf-local first.  Moreover if there are already some files/directories placed there then even 'rmdirm ...' in %pre is doomed
(luckily enough).

Changelog for this update claims that this is the following bug fix:

- make /usr/share/texmf visible to kpathsea, make texmf-local
pointing to it (#867656, #864875)

As a matter of fact this is a terrible idea which makes local packages truly inaccessible withough hacking a default configuration and bug #867656 actually strongly suggested some other approach.  In bug #864875 a temporary hack of making texmf-local into a symlink was a clear abuse serving as a workaround
to a damage inflicted by the previous update.  But this was even _not that symlink_ so nothing is "fixed" here but more damage inflicted.  Making a symlink, say 'backcompatible',in /usr/share/texlive/texmf/ to /usr/share/texmf/ would likely have much better effect; only one can avoid such hackery by amending a default search path in texmf.cfg

Version-Release number of selected component (if applicable):
  texlive-base-2012-3.20120926_r27815.fc19                             
  texlive-base-2012-3.20121019_r28030.fc19 

How reproducible:
always (unless somebody already damaged a default directory structure).

Comment 1 Michal Jaegermann 2012-10-20 20:20:03 UTC

As an extra attraction failed attempts to update leave "extra" links in a form
/usr/share/texlive/texmf-local;5082xxxx
which are rather "interesting" to remove due to a presence of ';'.  Even "simple quoting" is of not much help. :-)

Comment 2 Jindrich Novy 2012-10-21 03:17:55 UTC

Note this is rawhide. Please don't use it for production. Some adjustments need to be done so that TeX Live is properly usable on fresh installation of F19 and on. I will not keep update path clean among rawhide builds if it needs to be broken to fix some important things. This is what rawhide is actually for :)

Comment 3 Michal Jaegermann 2012-10-21 05:33:37 UTC

(In reply to comment #2)
> Note this is rawhide. Please don't use it for production.

Everything is true.  Only there are two details.  One is that this update
really kills a default TEXMFLOCAL by "merging" it with /usr/share/texlive/texmf/ so it is truly broken does not matter which way you look at it.  And the second is that contrary to claims in Changelog this does not fix neither bug 864875 nor
bug 867656.  If you want to close this obvious bug with NOTABUG I can only shrug.