On Wed, Dec 11, 2019 at 5:39 PM Kevin Kofler <kevin.kofler(a)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.
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
** 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
* 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
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.