#373 qt5 in epel10
Opened by tdawson. Modified

RHEL 10 will have qt6 in it. The SIG has already discussed and decided that the KDE Plasma Desktop in epel10 will be qt6 based.
But, the question is whether qt5 will be in epel10 at all, and if so, what are the conditions.
Here is my proposal. It has three parts.

Group 1 - qt5 packages that are in RHEL 9.
Since the RHEL 9 lifetime will cover most of the epel10 lifetime, have all the qt5 packages that are in RHEL 9, in epel10. They should be the same version and have the same patches whenever possible.

In the final three years of epel10, these packages will be updated in a "best effort" manner. It is possible that some might need to be retired during that time if there are sufficient security issues that cannot be addressed.

Group 2 - qt5 packages that are not in RHEL 9
QT5 packages that are not in RHEL 9 will be evaluated on a case by case basis. Those packages that have been problem packages in the past, It will be recommended that they do not be added to epel10. An example is qt5-qtwebengine.

These packages will be on "best effort" support from the beginning. It is possible that some might need to be retired at any time if there are sufficient security issues that cannot be addressed.

Group 3 - Packages based off qt5
It is discouraged for packages in epel10 to depend on qt5. Packages that can build on both qt6 and qt5 should only be built on qt6.

Packages that can only be built on qt5, can be built on qt5. When those packages have been ported to qt6, they should be updated to be qt6 only packages.


We will need to have Qt 5 and KF5 in EPEL 10. Most KDE Gear software will not be ported to Qt 6 immediately. So we'll probably have to do a variation of options 1 and 2.

We will need to have Qt 5 and KF5 in EPEL 10. Most KDE Gear software will not be ported to Qt 6 immediately. So we'll probably have to do a variation of options 1 and 2.

I figured the KF5 packages would land in part/group 3.

There aren't options, rather different types of packages that would have different support structures.

Group 1 - Those qt5 packages will get their support (updates) from RHEL 9.
Group 2 - Those qt5 packages will get their support (updates) from Fedora.
Group 3 - Those packages rely on qt5 from groups 1 and 2.

Maybe I'm overly complicating things. But I don't know how long we'll have qt5 support in Fedora.

I guess we could lump Group 1 and Group 2 together and say we'll support them as long as they are supported in Fedora, and after that it's "best effort".

That makes sense to me.

New Revision:

Here is my proposal. There are two groups of packages:

Group 1 - qt5 packages
QT5 packages will be evaluated on a package by package basis whether they will be added to epel10. Most qt5 packages will make it into epel 10, and will be supported as long as they are supported in Fedora. Those packages that have been problem packages in the past, will probably not be in epel10. An example or a problem package is qt5-qtwebengine. qt5-qtwebengine will probably NOT be in epel10.

If a qt5 package is no longer supported in Fedora, that package will be updated in epel10 on a "best effort" manner. It is possible that some qt5 packages might need to be retired if there are sufficient security issues that cannot be addressed.

Group 2 - Packages based off qt5
It is discouraged for packages in epel10 to depend on qt5. Packages that can build on both qt6 and qt5 should only be built on qt6.

Packages that can only be built on qt5, can be built on qt5. When those packages have been ported to qt6, they should be updated to be qt6 only packages.

Metadata Update from @timaeos:
- Issue set to the milestone: Red Hat Enterprise Linux 10.0
- Issue tagged with: epel

Metadata