Bug 1128240 - texlive-base should not touch user's /home directory
Summary: texlive-base should not touch user's /home directory
Alias: None
Product: Fedora
Classification: Fedora
Component: texlive
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1073518
TreeView+ depends on / blocked
Reported: 2014-08-08 16:33 UTC by Toshio Kuratomi
Modified: 2014-12-28 03:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-12-28 03:02:36 UTC

Attachments (Terms of Use)

Description Toshio Kuratomi 2014-08-08 16:33:05 UTC
Description of problem:

The %pre script of texlive has the following:

rm -rf /usr/share/texlive/texmf-var
rm -rf /var/lib/texmf/*
for i in `find /home/* -type d -prune`; do
rm -rf $i/.texlive*

The piece about deleting from /home/USER is a problem.

We probably shouldn't be touching any files under the user's home directory to begin with for similar reasons as we don't allow packages to touch /srv.  /home/USER is modified by users in arbitrary ways so packages really should not be touching those directories at all.  I talked to some people here at flock who convinced me we should probably update the packaging guidelines to make this explicit.  Created a ticket for that: https://fedorahosted.org/fpc/ticket/451

I believe that you're doing this so that texlive upgrades can work out of the box (I saw that the .fmt files under the user's .texlive directory can cause tex to stop working if the previous version of texlive which generated those are different.)

The right thing to do here is probably to patch texlive to detect the outdated fmt files and let something(s) within texlive delete them if necessary.  Another options could be to modify the error message to tell users what the likely workaround to the problem they encounter would be.

If you'd rather wait for FPC to decide whether packages can touch files in /home/$USER before making a final decision, there are some ways to make the scriptlet somewhat safer.  Something like this:

for user in `find /home/* -type d -prune`; do
  if test -d "$user/.texlive/texmf-var/web2c/" ; then
    for fmt_file in `find "$user/.texlive/texmf-var/web2c/" -type f -name '*.fmt'` ; do
      # mv might be better in some cases but since these should be just caches
      # if we've detected the right sort of files anyhow,  I suppose this is best.
      rm -f  "$fmt_file"

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. rpm -q --scripts texlive-base

Actual results:

See a %pre scriptlet that rm's files in a user's home dir

Expected results:

Do not see a scriptlet that rm's files in a user's home dir.

Additional info:

Comment 1 Toshio Kuratomi 2014-08-12 15:40:24 UTC
Updating with either the new scriptlet or not touching the user's home directory at all will fix this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1073518

Comment 3 Toshio Ernie Kuratomi 2014-08-21 15:09:58 UTC
FPC has decided that indeed, packages cannot touch /home/$USER.  So the scriptlet needs to be removed.  Short term, documentation could be adjusted to tell people why texlive isn't working (which seems to be the route taken by Arch Linux, for instance), and one of the alternatives involving modifying texlive can be pursued in the future.

Comment 4 Christopher Meng 2014-12-28 02:23:06 UTC
We still haven't received any responses from the maintainer, what's the progress here?

Comment 5 Jason Tibbitts 2014-12-28 02:37:34 UTC
I saw changes to fix this committed very recently.


Note You need to log in before you can comment on or make changes to this bug.