On Wed, Dec 11, 2019 at 5:39 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> 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 Kofler Just 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. _______________________________________________ kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@xxxxxxxxxxxxxxxxxxxxxxx
