Proposed as a Freeze Exception for 33-beta by Fedora user zbyszek using the blocker tracking app because:

 Breaks upgrade to F33.

This is weird. Can you attach the full log from dnf system-upgrade? Why is texlive-kpathsea kept in the fc32 version? In F33, there's a new version in the main repo:

[kparal@f33 ~]$ sudo dnf install texlive-texlive-scripts texlive-kpathsea
Dependencies resolved.
================================================================================
 Package                        Arch   Version                    Repo     Size
================================================================================
Installing:
 texlive-kpathsea               x86_64 7:20200327-15.fc33         fedora  1.1 M
 texlive-texlive-scripts        noarch 7:20200327-15.fc33         fedora  108 k
...

And I can successfully install both at the same time.

> Why is texlive-kpathsea kept in the fc32 version? 

I assume there was some other conflict which was preventing the upgrade. I had a bunch
of different upgrade issues, so it was probably related to one of them.
I didn't keep the logs though, sorry.

I can install both .fc33 version now without trouble.

If texlive-texlive-scripts.fc33 conflicts with texlive-kpathsea.fc32 then it should
have an explicit versioned Conflicts line.

I'm not a packaging expert but I thought you can easily move a file from one package to a different one, if you submit both packages as a single update together (even as an update to a stable distro), so that the end user receives both of them at the same time, and you don't need to add explicit conflicts in this case. All fc33 packages are supposed to be present in the same transaction (distro upgrade), so there's no need to have fc32<->fc33 conflicts definitions. But I might be wrong of course.

Putting such packages in a single update is the minimum. Without that people are almost certain to have issues,
since the updates are most likely to not go stable at the same time. But still it's not enough to prevent
issue in case on the updates is held back by some other conflict, or if the user tells dnf to upgrade just
one package for whatever reason. For pleasant user experience it is necessary to have any file conflicts
"guarded" by explicit versioned Conflicts or Requires so that dnf can figure out the transaction requires
additional packages. If the conflict is detected at the file level in the transaction verification stage
dnf can only give up.

In the version of texlive in Fedora 32, these binaries were in the upstream "kpathsea" component:

mktexlsr
mktexmf
mktexpk
mktextfm

In the newer version of texlive in Fedora 33, they were moved (by upstream) to the "texlive-scripts" component.

There is no intention for "texlive-kpathsea" and "texlive-texlive-scripts" to conflict, and neither obsoletes the other (they are both present in Fedora 32 and 33). The only way that they conflict is if you somehow create a mixed transaction with some texlive subpackages from Fedora 32 and others from Fedora 33.

In Fedora 33, texlive-kpathsea has: Requires(post): texlive-texlive-scripts. This is an unversioned requires, because I assumed that there would never be a scenario where some of the corresponding subpackages of texlive-base would be in a transaction, but not all of them. I'm still not sure _how_ you managed this, but I will make this Requires versioned so that the transaction will simply fail if this is ever the case.

What usually turns out to be the problem in this case is that something else in the transaction causes dnf to try and keep the older package. i.e. there was something installed which required something that texlive-kpathsea-7:20190410-12.fc32.x86_64 provides but texlive-kpathsea-7:20200327-15.fc33.x86_64 doesn't, and that package either:

i) has no updated F33 version available, but isn't obsoleted by anything; or
ii) has an updated F33 version available, but *that* can't be installed due to some other dependency issue

this is likely to have been the "real bug" here, but if zbigniew's logs aren't enough to show what that problematic package might have been, it's hard to debug.

FEDORA-2020-2ddf923ccf has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2ddf923ccf

Discussed at 2020-09-21 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2020-09-21/f33-blocker-review.2020-09-21-16.00.html . Rejected as a freeze exception issue as this only happened because something was causing the old F32 package to stick around, and we don't have enough information to find out what that was and fix it. Adding the versioned Requires: will be useful but doesn't really need to go in as an FE.

FEDORA-2020-2ddf923ccf has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2ddf923ccf`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2ddf923ccf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-2ddf923ccf has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.