Bug 1577224

CC'ed the emacs-auctex maintainer.

*** Bug 1577457 has been marked as a duplicate of this bug. ***

Fixing this by removing the preview subpackages from texlive, the ones generated by emacs-auctex are newer than what is in TeXLive.

I assume that this also means that tex-preview then provides texlive-preview, or?

Not exactly. They both had the same tex files inside them (well, the texlive ones were slightly older), but nothing depended on "texlive-preview", so it's fine.

I'm waiting on https://bugzilla.redhat.com/show_bug.cgi?id=1568308 to roll out a fix, otherwise, I have to tear out a ton of packaging cleanups (and I'd really rather not).

Ok, thought texstudio depends on it, but then I'll need to change the Requires.

*** Bug 1541658 has been marked as a duplicate of this bug. ***

For me, this blocks upgrading from fedora 27 to 28.

I also ran into https://bugzilla.redhat.com/show_bug.cgi?id=1566070 but that issue could be worked around. This bug show up afterwards. 

It appears that there is no way to work around this other than simply removing Latex? (not that it would be viable in my case though)

The error output when upgrading is as follows:

Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
  file /usr/share/texlive/texmf-dist/tex/latex/preview/preview.sty conflicts between attempted installs of tex-preview-12.1-3.fc28.noarch and texlive-preview-6:svn38865-42.fc28.2.noarch

Error Summary
-------------

Aside: Nothing should ever depend on texlive-anything since all texlive-foo packages should be providing tex(foo), and packages should only ever Require tex (foo).

Thanks for fixing this Tom. Actually this was a regression - I remember Jindrich fixing the same problem many years ago when he moved to the current packaging mechanism.

I just checked and emacs-auctex and the subpackage tex-preview provide tex(preview.sty) is this then the same as tex(preview)? Just to be sure that the transition then will work.

(In reply to Jonathan Underwood from comment #9)
> Aside: Nothing should ever depend on texlive-anything since all texlive-foo
> packages should be providing tex(foo), and packages should only ever Require
> tex (foo).
> 
> Thanks for fixing this Tom. Actually this was a regression - I remember
> Jindrich fixing the same problem many years ago when he moved to the current
> packaging mechanism.

Ok, but apparently that's not true for all packages:
rpm -q --provides texlive-dvipng
tex-dvipng = 2016
texlive-dvipng = 6:svn40768-42.fc28.2

I added both of the deps now correctly to my spec file. Is there anywhere some documentation on the correct dependency listing of tex packages? I could not find anything via a search on the internet.

(In reply to hannes from comment #11)
> (In reply to Jonathan Underwood from comment #9)
> > Aside: Nothing should ever depend on texlive-anything since all texlive-foo
> > packages should be providing tex(foo), and packages should only ever Require
> > tex (foo).
> > 
> > Thanks for fixing this Tom. Actually this was a regression - I remember
> > Jindrich fixing the same problem many years ago when he moved to the current
> > packaging mechanism.
> 
> Ok, but apparently that's not true for all packages:
> rpm -q --provides texlive-dvipng
> tex-dvipng = 2016
> texlive-dvipng = 6:svn40768-42.fc28.2
> 
> I added both of the deps now correctly to my spec file. Is there anywhere
> some documentation on the correct dependency listing of tex packages? I
> could not find anything via a search on the internet.

Hmm. I can't find it in the packaging guidelines either, though I am sure it was their once. Or perhaps it existed only as a draft. However, you can see that the packages do generally follow the prescription I outlined. Picking one at random:

$ rpm -q --provides texlive-threadcol
tex(threadcol.sty) = 2016
tex-threadcol = 2016
texlive-threadcol = 6:svn28754.1.0-42.fc28.2


The first two virtual provides patterns (i.e. tex(foo.sty) and tex-foo) are always present, or should be.

dvipng seems to be an anomaly - I think that's a packaging bug.

(In reply to hannes from comment #10)
> I just checked and emacs-auctex and the subpackage tex-preview provide
> tex(preview.sty) is this then the same as tex(preview)? Just to be sure that
> the transition then will work.

Yes, tex(preview.sty) is correct.

[I typo'd earlier with tex(foo) - that would be tex(foo.sty) for style files/class packages.]

(In reply to Jonathan Underwood from comment #9)
> Aside: Nothing should ever depend on texlive-anything since all texlive-foo
> packages should be providing tex(foo), and packages should only ever Require
> tex (foo).
(In reply to Jonathan Underwood from comment #12)
> dvipng seems to be an anomaly - I think that's a packaging bug.

$ rpm -q --requires texstudio
...
tex(latex)
texlive-dvipng
texlive-preview

There's another one, which breaks a 400M update. Workaround: Uninstall tex-preview. Emacs, emacs-auctex and some other packages - 112M overall - are removed automatically. Reinstall emacs, install auctex from inside emacs (with list-packages e. g.) (melpa). But Texstudio's preview is gone.

I've fixed that one with the latest update texstudio-2.12.8-7.fc28.x86_64:
$rpm -q --requires texstudio
...
tex(latex)
tex(preview.sty)
tex-dvipng

texlive-2016-44.20160520.fc28 texlive-base-20170520-29.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-694af37c58

I was able to work around 1568308 by using %posttrans scriptlets to clean up the mess, so this update is getting pushed.

Glad the hack is actually functional.  I do still think it's possible to avoid the nastiness of all those packages individually commenting lines in and out of fmtutil.cnf and that the end result would be far more pleasant; I'm happy to work on that a bit if you like.

texlive-2016-44.20160520.fc28, texlive-base-20170520-29.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-694af37c58

emacs-auctex-12.1-4.fc28 texlive-2016-44.20160520.fc28 texlive-base-20170520-29.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-694af37c58

emacs-auctex-12.1-4.fc28, texlive-2016-44.20160520.fc28, texlive-base-20170520-29.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-694af37c58

emacs-auctex-12.1-4.fc28, texlive-2016-44.20160520.fc28, texlive-base-20170520-29.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Updating from fedora 26 to fedora 28. I got the same issue.
What to do?

I have renamed /var/lib/dnf/history and started an upgrade about 10 hours ago. It's still running (>7k upgrades). Dnf created a /var/lib/dnf/history.sqlite.

George...

oops. wrong bug report.