Bug 585152

Summary: texlive packages need to Require(postun) texlive-tetex
Product: [Fedora] Fedora Reporter: Mary Ellen Foster <mefoster>
Component: texliveAssignee: Jindrich Novy <jnovy>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: jnovy, pertusus, pknirsch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-03 15:33:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Output of "yum remove texlive\*"
none
Installation of the same package set on F13 none

Description Mary Ellen Foster 2010-04-23 09:31:50 UTC
Description of problem:
I'm just doing one more big uninstall/reinstall of texlive-* on a different computer, and I noticed a lot of this sort of thing in the output during the uninstall transaction:
Erasing        : texlive-gsftopk-2010-4.1.19.2.16044.fc13.noarch                          185/219 
sed: can't read /usr/share/texlive/texmf/web2c/updmap.cfg: No such file or directory
sed: can't read /usr/share/texlive/texmf/web2c/updmap.cfg: No such file or directory
sed: can't read /usr/share/texlive/texmf/web2c/updmap.cfg: No such file or directory
sed: can't read /usr/share/texlive/texmf/web2c/updmap.cfg: No such file or directory
sed: can't read /usr/share/texlive/texmf/web2c/updmap.cfg: No such file or directory
sed: can't read /usr/share/texlive/texmf/web2c/updmap.cfg: No such file or directory

It seems to me that any packages that need to make use of updmap.cfg when they're being erased should Require(postun) whatever package provides that file, which seems to be texlive-tetex.

(I think I mentioned this on IRC but I wanted to make sure it didn't slip through ...)

Version-Release number of selected component (if applicable):
texlive-2010-4.20100421.fc12.x86_64.rpm

How reproducible:
Every time

Steps to Reproduce:
1. yum remove texlive\*

Comment 1 Jindrich Novy 2010-04-23 10:50:24 UTC
Currently scriptlets have these dependencies in case updmap call is needed:

Requires(posttrans): texlive-kpathsea-bin = %{tl_version}
Requires(posttrans): texlive-tetex-bin = %{tl_version}
Requires(post,postun): texlive-tetex-bin = %{tl_version}
Requires(post,postun): texlive-kpathsea-bin = %{tl_version}

This should be enough to satisfy the dependencies for the scriptlets (texlive-kpathsea-bin is dependent on texlive-kpathsea and texlive-tetex-bin is dependent on texlive-tetex) so the updmap.cfg should remain in place (at least as far as I have tested). I tried to install and uninstall texlive and the only message I saw in the log was:

  Erasing : texlive-tetex-2010-4.3.0.16770.fc13.noarch                  213/217 
warning: /usr/share/texlive/texmf/web2c/updmap.cfg saved as /usr/share/texlive/texmf/web2c/updmap.cfg.rpmsave
  Erasing : texlive-tetex-bin-2010-4.20100421.fc13.16487.fc13.x86_64    214/217
  Erasing : texlive-kpathsea-2010-4.17541.fc13.noarch                   215/217 
warning: /usr/share/texlive/texmf/web2c/fmtutil.cnf saved as /usr/share/texlive/texmf/web2c/fmtutil.cnf.rpmsave
  Erasing : texlive-kpathsea-bin-2010-4.20100421.fc13.16044.fc13.x86_64 216/217 
  Erasing : texlive-kpathsea-lib-2010-4.20100421.fc13.x86_64            217/217

Strange thing is that texlive-gsftopk doesn't need to call updmap or touch the updmap.cfg at all. Maybe it's some relict of pre-2010-4 packages?

Comment 2 Mary Ellen Foster 2010-04-23 11:05:13 UTC
Created attachment 408575 [details]
Output of "yum remove texlive\*"

I just tried again with the uninstall, and I got the same errors. Here's the full output of the yum transaction -- perhaps the output messages refer to the package after them rather than before them?

Comment 3 Jindrich Novy 2010-04-23 11:58:19 UTC
Created attachment 408586 [details]
Installation of the same package set on F13

It seems that there is no erasure ordering in yum/rpm in F11 and F12 what corrupts the (un)installation there. So it is actually yum or rpm's bug. I'm using F13 with yum-3.2.27-3.fc13.noarch and rpm-4.8.0-10.fc13.x86_64 and see no problems as my log shows.

Comment 4 Jindrich Novy 2010-04-23 11:59:05 UTC
Seems like everyone wants to upgrade to Fedora 13 ;)

Comment 5 Mary Ellen Foster 2010-04-23 12:07:51 UTC
Hmm, on my F12 computer I have:
yum-3.2.27-3.fc12.noarch
rpm-4.7.2-1.fc12.x86_64

So the version of yum is the same, but rpm is older, so it seems like it's an RPM issue.

... and reading the rpm 4.8 changelog at http://rpm.org/wiki/Releases/4.8.0, it seems like that is the case -- here's an interesting bullet point (edited to make the links work in bugzilla):
- Package erasures are now ordered too (ticket #48, bug 479257, bug 448153)

Comment 6 Bug Zapper 2010-11-03 16:30:57 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Bug Zapper 2010-12-03 15:33:18 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.