On Wed, Dec 11, 2019 at 8:42 PM Troy Dawson tdawson@redhat.com wrote:
On Wed, Dec 11, 2019 at 5:39 PM Kevin Kofler kevin.kofler@chello.at wrote:
Troy Dawson wrote:
The biggest reason for building it as a module is the qt5 packages in RHEL8. If RHEL8 didn't have any of those, then I would completely agree with you.
To be honest, I am not convinced that replacing RHEL's Qt 5 (and making that a requirement for the KDE software stack) is a good idea. It will break at least some Qt applications in RHEL itself (unless the module rebuilds them too) and some third-party ones (and you cannot rebuild those). While Qt is backwards-compatible in principle (so you can often get away with just upgrading it), please be warned that everything relying on private APIs WILL break if not rebuilt (and there is a bunch of offenders there, unfortunately), and some other applications might break due to behavior changes. (Looking at what rebuilds get bundled with Fedora Qt upgrades may give you a hint at affected packages. But of course it won't include anything proprietary or otherwise third-party.)
I think it may be better to stick to whatever can be built with RHEL's Qt 5.11.x and the EPEL QtWebEngine 5.12.x that I helped you build. Upgrading to QtWebEngine 5.12.x LTS security releases should be safely possible. (Please do that!) For RHEL stuff, let RH deal with security. Hopefully, they will eventually include a newer Qt in an update release.
Kevin KoflerJust a few things to keep things in perspective.
- If we build a kde module, and it is not labeled "default", unless
you enable that module, you won't get those libraries. You are making it sound like if we make a module, we wipe out RHEL8's qt5 libraries. It won't. So if a third-party builds against those, then their packages still work.
- There is nothing in RHEL8 that requires the qt5 libraries. (And by
qt5 libraries, I mean all the qt5 packages in RHEL8, not just qt5)
- It's nice to hope that RHEL8 will update qt5 to the LTS version. Do
you have any bugzilla's that are asking for that? If so, what is Red Hat's response? ** History shows that they won't update it unless there is some real reason. Because, as you've stated above, it will break third party packages.
- It's possible that someone can build a KDE desktop on regular
non-module EPEL8 ... AND ... we can have a KDE module that fully tracks Fedora's version of KDE. But that someone will not be me. ** I already have the initial work done in epel8-playground, so if someone want's to do this they won't have to start from scratch. But if they do this, I suggest they trim down the list of packages from 300+ to something they feel they can support for 8 to 10 years. I think I went a little overboard when I created my list of KDE packages.
Troy p.s. I hope my tone with this doesn't sound angry, I'm not. I'm just trying to make sure people understand what the workload would be.
Hi Kevin, I've had the night to sleep on it, and I now see that you are totally right. I was getting so excited about the ability to always have a newer KDE on RHEL, that I forgot the reason I run RHEL and it's clones in the first place ... stability.
I was also being very arrogant, thinking I would do everything. The old saying "Just because you can do something, doesn't mean you should." comes to mind. Because I was thinking that, I had this "one person" mentality in my head, that one person had to do it all.
Granted, it was probably good for me to go through the entire kde and get it working on RHEL8. But I don't own the packages in Fedora, and I wasn't giving those package owners any chance to say anything for the EPEL8 packages.
I would still like to do a module that tracks rawhide. But how about we have a discussion, possibly on both epel-devel as well as the fedora kde list, about the correct way to do KDE in EPEL8. I really like your idea of following the LTS branch.
Troy