dnf system-upgrade isn't supported on RHEL so I am not surprised it wasn't tested.

A Neal said, nope, I didn't test it. But I'm a little surprised because I thought those obsoletes would have been in the spec files already because Fedora did do update testing.

But, no matter the reason, let's get those obsoletes in there.

At least for libkscreen-qt5, the reason we didn't is because in Fedora, the package still exists, we just shuffled things around to make them not conflict anymore.

after some research, I found the source of the kuserfeedback conflicts,I didn't rebuild it properly so the rhel >=10 compat wasn't in (which means in epel10 this should work automatically)

@ngompa dnf system-upgrade isn't supported on RHEL so I am not surprised it wasn't tested.

https://rpmfind.net/linux/RPM/centos-stream/9/baseos/x86_64/dnf-plugins-core-4.3.0-15.el9.noarch.html

has dnf-plugin-system-upgrade included, I updated my systems from 8 to 9 with a backport of that package to rhel 8 and did my upgrades with that. So either way if it's supported or not, if it's part of the system it should be and it works for upgrading to 10 :)

konsole has an Obsoletes, but konsole-part does not. That needs to get fixed.

We took extra care of this when packaging Plasma 6.

All the issues you mention are already resolved, you just need to take the new versions of the qt5 packages from fedora:

• konsole5: https://src.fedoraproject.org/rpms/konsole5/
• libkscreen-qt5: https://src.fedoraproject.org/rpms/libkscreen-qt5
• kuserfeedback: https://src.fedoraproject.org/rpms/kuserfeedback (has a conditional for rhel 10)
• kf5-kldap: https://src.fedoraproject.org/rpms/kf5-kldap

There are no Conflicts stanzas in place because only the fixed versions exist in the Fedora 40+ repos, and the same will be true for EPEL 10. The issue is only present in your copr.

We took extra care of this when packaging Plasma 6.

All the issues you mention are already resolved, you just need to take the new versions of the qt5 packages from fedora:

• konsole5: https://src.fedoraproject.org/rpms/konsole5/
• libkscreen-qt5: https://src.fedoraproject.org/rpms/libkscreen-qt5
• kuserfeedback: https://src.fedoraproject.org/rpms/kuserfeedback (has a conditional for rhel 10)
• kf5-kldap: https://src.fedoraproject.org/rpms/kf5-kldap

There are no Conflicts stanzas in place because only the fixed versions exist in the Fedora 40+ repos, and the same will be true for EPEL 10. The issue is only present in your copr.

it's not, I installed plasma 5 from epel9 packages. The issue then is to update the epel9 packages inside epel9 repos so they are upgradeable without conflicts.

There is no need for that in EPEL9 because there is no Plasma 6 in EPEL9.

On second thought though, if the plan for EPEL10 is to drop the qt5 packages then there are indeed some Obsoletes to be added so that the old packages from epel9 are not left around. Thus reopening for Troy to evaluate.

@aleasto please have a look here:
https://src.fedoraproject.org/rpms/kf5-kldap/blob/epel9/f/kf5-kldap.spec
vs.
https://src.fedoraproject.org/rpms/kf5-kldap/c/4ce6c04d86fdda8d88ca62a4e577ea965a789dc4?branch=f40

your patch from f40 is missing in epel9 which creates the conflicts when upgrading epel9 to epel10:

• Rename translation files to avoid conflict with KF6

  
  71
  • find ./po -type f -name kio_ldap.po -execdir mv {} kio_ldap5.po \;
    72

your patch from f40 is missing in epel9 which creates the conflicts when upgrading epel9 to epel10:

Yes, so you would need the patch in epel10, not epel9.

But as I remembered above, the plan is to not have the package at all in epel10 so there should be Obsolete stanzas conditionalized for RHEL only (because the package still exists in Fedora)

your patch from f40 is missing in epel9 which creates the conflicts when upgrading epel9 to epel10:

Yes, so you would need the patch in epel10, not epel9.

But as I remembered above, the plan is to not have the package at all in epel10 so there should be Obsolete stanzas conditionalized for RHEL only (because the package still exists in Fedora)

kf5-kldap doesn't have an epel10 branch :) the patch needs to be added to the epel9 branch and the package in epel9 has to be updated afterwards - @tdawson ?

There isn't anything to fix in EPEL 9 because KF6 isn't going into EPEL 9 at all.

There isn't anything to fix in EPEL 9 because KF6 isn't going into EPEL 9 at all.

sigh I know :) the fixes are needed for kf5 based packages in epel9 that get updated by kf6 packages in epel10, obviously when upgrading rhel9 + epel9 systems to rhel10 + epel10 smoothly

Fixing the package in epel9 so that when it's left behind on upgrade it does not conflict with newer packages is just backwards.

You should either provide the patched kf5 packages that does not conflict anymore in epel10, or add Obsoletes to the kf6 packages so that the conflicting packages are not left behind.

Because we already decided to not include the kf5 stack in epel10, the solution is the latter: add Obsolete stanzas to the kf6 packages. And remember to make it conditional for %rhel only because we don't want to kill kf5 in Fedora just yet.