Bug 1568308
Summary: | TeX: pdflatex is broken when upgrading to F29 (until reinstalled) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Miro Hrončok <mhroncok> |
Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | dimhen, dmach, fedora, ignatenko, mhatina, mjw, packaging-team-maint, pmatilai, pmoravco, rpm-software-management, tcallawa, vmukhame |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-06-01 15:20:08 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1505342 |
Description
Miro Hrončok
2018-04-17 08:20:47 UTC
What a mess. I think the issue is this: texlive-latex-bin-bin (f28) is obsoleted by texlive-latex (rawhide). The %postun scriptlet for texlive-latex-bin (not bin-bin) counts the number of instances of "texlive-latex-bin" which will be left on the system after the transaction and finds "0", thus, the scriptlet to comment out the bits in fmtutil.cnf happens. Now, the %post scriptlet for texlive-latex is conditionalized on "if [ $1 -gt 0 ]", which should trigger when the number of instances of texlive-latex after the transaction is greater than 0 (1 is install, 2 is upgrade), so it should _always_ be running here, and it is. When I do the dnf --releasever rawhide distro-sync --nogpgcheck --rpmverbosity=debug I see that the texlive-latex scriptlet executes at 287/631 (enable in fmtutil.cnf), but the texlive-latex-bin scriptlet executes at 357/631 (disable in fmtutil.cnf) Upgrading : texlive-latex-7:20170520-27.fc29.noarch 287/631 Running scriptlet: texlive-latex-7:20170520-27.fc29.noarch 287/631 ... Obsoleting : texlive-latex-bin-6:svn41438-42.fc28.2.noarch 357/631 Running scriptlet: texlive-latex-bin-6:svn41438-42.fc28.2.noarch 357/631 Because dnf is doing the obsolete action later in the transaction, we get the disable scriptlet run after the enable scriptlet. Obviously, when you reinstall, there is just the texlive-latex (rawhide) package in the transaction, so the scriplets get run properly (disable from the uninstall, then enable from the install). I don't know how to fix this. The scriptlets in the texlive-latex (rawhide) and texlive-latex-bin (f28) package are correct. I do not know of a way to tell a scriptlet to not execute when it is being obsoleted. I think this might be a dnf bug, where dnf needs to run the Obsoleting step before Upgrading the package that obsoletes it (instead of doing it afterwards). Reassigning to dnf. FWIW, I had hoped to push texlive 2017 to Fedora 28 after release, but until this bug is resolved, I do not think we can do that. This bug should probably be considered a Fedora 29 blocker. I really need to update texlive in Fedora 28. Any chance of fixing this bug soon? I was able to work around this using %posttrans scriptlets to force the config to re-enable if the binaries relating to the texlive subpackages are present, but I still think this should be fixed in dnf. It's rpm that decides the order of transaction execution, there's nothing dnf can do about this. And there's no easy fix from rpm side that I can think of either: You cannot do erasures (ie what's shown as "obsoleting" by dnf here) before installs, it'd be like pulling the rug from under yourself. Perhaps there should be some way to determine the obsoletion case from scriptlets, but then you'd often need something special in the package being obsoleted, and you hardly ever *plan* for a package getting obsoleted when creating it. For a case like this it might be enough to pass scriptlet arguments similar to upgrade case to the obsoleted package (so it'd be handled via the usual upgrade logic in scriptlets), but in other cases you want the exact opposite (ie let the obsoleted package truly erase itself). So there'd need to be some way to indicate the desired behavior from the obsoleting package. Okay. That makes sense. Since I think texlive might be the only package which hits this state, and I've worked around it effectively, I'm just going to close this one out. |