Description of problem: When upgrading to rawhide (Fedora 29), pdflatex cannot be used until reinstalled. Version-Release number of selected component (if applicable): texlive-base-20170520-27.fc29 texlive-latex-20170520-27.fc29 How reproducible: Simulate an upgrade in mock. $ mock -r fedora-8-x86_64 --init $ mock -r fedora-8-x86_64 --install dnf $ mock -r fedora-rawhide-x86_64 --enable-network --shell # dnf install /usr/bin/pdflatex # grep pdflatex /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf pdflatex pdftex language.dat -translate-file=cp227.tcx *pdflatex.ini # dnf --releasever rawhide distro-sync --nogpgcheck # grep pdflatex /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf #! pdflatex pdftex language.dat -translate-file=cp227.tcx *pdflatex.ini # cat > doc.tex << EOF \documentclass{article} \begin{document} \end{document} EOF # pdflatex doc.tex ... I can't find the format file `pdflatex.fmt'! # dnf --releasever rawhide reinstall /usr/bin/pdflatex --nogpgcheck # grep pdflatex /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf pdflatex pdftex language.dat -translate-file=cp227.tcx *pdflatex.ini # pdflatex doc.tex .. OK I assume the problem is with scriptlets + moving /usr/bin/pdflatex from texlive-latex-bin-bin into texlive-latex. I assume pdflatex get's commented in fmtutil.cnf when texlive-latex-bin-bin is being removed, and that happens after texlive-latex is added. But this is pure speculation.
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.