On Wed, Dec 11, 2019 at 8:42 PM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > 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. 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 _______________________________________________ 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
