On Wed, Dec 11, 2019 at 2:37 PM Neal Gompa ngompa13@gmail.com wrote:

On Wed, Dec 11, 2019 at 3:25 PM Troy Dawson tdawson@redhat.com wrote:

...

Hi, As the final bugs of modularity in EPEL 8 get worked out, I'm working on the plan for the kde modules. Right now, I'm leaning towards a great big kde module with all the kde packages in it. There would be two streams. rawhide and stable.

rawhide would follow the fedora master dist-git branch. It would get updated at least once a month, or faster. No quicker than ever two weeks, because that's how long it takes for things to go through bodhi. I'm leaning towards once a month.

stable would follow the stable Fxx branch, and get updated every three months, or when security and/or major bugs happen.

The modules would have *all* the qt5 packages in them, including those that are in RHEL8. Because of this, we will not be able to mark them as "default". People will have to enable them to use them.

I am currently working my way through all the packages, making sure they build and making fixes in rawhide/master when they don't. I think there should only be about 15 to 20 packages that need tweaking.

Thoughts and/or comments?

I'm increasingly wondering if it's a good idea to ship KDE as a module. The number of issues being discovered (including inability to discover and deal with security issues) makes me think we might want to consider shipping it as a normal set of packages...

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.

If it's possible to have just those packages as a module, and the rest without ... that might work too. But then you would have a weird situation where you have lots of packages that look like they will install, but won't because they require a different qt5 that what looks obvious. But I'm not even sure if that will work. koji is going to see the non-module packages, (from RHEL8) and use them for building.

Troy

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 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.

Troy Dawson wrote:

• 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.

But they may be incompatible with your KDE module. (Or they may not, thanks to Qt's backwards binary compatibility. But there is the possibility of such an incompatibility, so that is what I am warning about.)

Please note that it is not my intent to force you to do anything. The one who does the work decides. I am just making suggestions and warning about the possible implications of some decisions.

(In Fedora proper, I would rather not see any modules at all, but EPEL is a different story because RHEL 8 itself relies a lot on Modularity. So in the end, it is a decision the EPEL packagers (which I am not) have to make on a case by case basis.)

Kevin Kofler

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 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

On Thu, Dec 12, 2019 at 9:59 AM Troy Dawson tdawson@redhat.com wrote:

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.

On the other hand, particularly when it comes to desktops/workstations, one of the problems with RHEL and the clones is you end up unable to run the software you want because the outside desktop software ecosystem has move too far forward after about 3 years let alone the full length of support for those releases (as there is in a way an acknowledgement from Red Hat on this issue, where they now provide newer compilers and associated stuff on the side to reflect the reality that compilers/languages are moving at a much faster pace than when RHEL had its first release).

So as a user, I think the first question is perhaps what sort of KDE experience do the people willing to do the work to make it available on RHEL want to provide. If you want to make it stay at the same release as when first offered, then RPMS might provide the best/easiest solution to make it available. On the other hand, if you either want to keep it up to date or use a 2 or 3 release cycle, then perhaps the module route might be more appropriate given that some key things are controlled by Red Hat.