Bug 1568308 - TeX: pdflatex is broken when upgrading to F29 (until reinstalled)
Summary: TeX: pdflatex is broken when upgrading to F29 (until reinstalled)
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1505342
TreeView+ depends on / blocked
 
Reported: 2018-04-17 08:20 UTC by Miro Hrončok
Modified: 2018-06-01 15:20 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-01 15:20:08 UTC
Type: Bug


Attachments (Terms of Use)

Description Miro Hrončok 2018-04-17 08:20:47 UTC
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.

Comment 1 Tom "spot" Callaway 2018-04-17 15:01:33 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.

Comment 2 Tom "spot" Callaway 2018-04-30 15:12:36 UTC
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.

Comment 3 Tom "spot" Callaway 2018-05-14 18:18:59 UTC
I really need to update texlive in Fedora 28. Any chance of fixing this bug soon?

Comment 4 Tom "spot" Callaway 2018-05-30 18:24:35 UTC
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.

Comment 5 Panu Matilainen 2018-05-31 09:48:38 UTC
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.

Comment 6 Tom "spot" Callaway 2018-06-01 15:20:08 UTC
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.


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