On Fri, Apr 29, 2022 at 12:19 PM Troy Dawson <tdawson@redhat.com> wrote:
On Fri, Apr 29, 2022 at 11:28 AM Germano Massullo <germano.massullo@gmail.com> wrote:
Recent CentOS Stream Qt update broke some EPEL packages like keepassxc
that needed a rebuild against the new Qt version.
Can we talk about a way to prevent this from happening again?

Best regards

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2077742
 
The qt5 version went from 5.15.2 to 5.15.3 in CentOS Stream, thus packages that depend on specific version of qt5 need to be rebuilt, in just epel8-next.
That means that in RHEL 8.7 those same versions are going to change and need a rebuild again.

What do you suggest would be a good way to prevent this in the future.

Troy

So, my mind isn't letting this go.
There are going to be updates in RHEL and CentOS Stream, that is just the nature of software and operating systems.

But what if we got an early warning system?  Would it be worth it?

The RHEL 9 workflow (and hopefully RHEL 8 sometime reasonably soon) starts with a build on CentOS Stream 9.
That build is tagged with c9s-gate, and then it goes through a variety of tests.
If everything goes well it get's tagged into c9s-pending.
At that point it goes into the CentOS Stream 9 development compose (once a day).
That development compose goes through more tests and if everything looks good a production compose is made.
Again, more tests, then signing and it get's pushed to the mirrors and all the other places.

Anyway, all the CentOS STream 9 (hopefully 8 soon) is publically visible.  It would be possible for someone to create a type of early warning system that let's maintainers know that a change is coming down the road and they will need a rebuild or something.

And ... now I just realized that this sounds alot like taking my Will-It-Install and pointing it at the CentOS Stream 9 development compose.

But if someone wants to design their own things that does this, that would be cool.

Troy