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\*
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?
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?
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.
Seems like everyone wants to upgrade to Fedora 13 ;)
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)
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
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.