On Mon, 2 May 2022 at 04:22, Alex Iribarren <alex.m.lists3@xxxxxxxxx> wrote:
Hi,
On 4/29/22 21:17, Stephen John Smoogen wrote:
>
>
> On Fri, 29 Apr 2022 at 14:28, Germano Massullo
> <germano.massullo@xxxxxxxxx <mailto:germano.massullo@xxxxxxxxx>> 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?
>
>
> This is the current situation of events for dealing with CentOS Stream
> and EPEL
> 0. Packages get put into stream at the rate of internal developers doing
> things and getting stuff put into GIT. There is no communication to know
> when this will happen so knowing what packages to build before this
> drops isn't happening.
> 1. The QT packages in Stream have taken a week to be fixed due to
> various issues found in them. [Mostly they were built in the wrong order
> and linked against each other poorly.]
So how could we stop this from happening in the future? The
We can't stop it from happening in the future. Pretty much every time I have seen it is because something changed in the 'way things have been done previously' and so it looked like a new problem with the same similarities. I think we can offer solutions to make this better and possibly help implement prototypes to show that they work or not.
50_test_comps[0] test caught some of the problems, but not all because
not all qt5 packages seem to be listed in a comps group. `dnf install
qt5-*` is unlikely to work, though I haven't tried.
How could we test that all qt5 packages have been correctly rebuilt? If
that's done right, the following steps will be a lot less painful.
I think the primary issue is that the crafting of binary packages is 'fairly' manual. Someone has to put the src.rpm in the meat grinder (koji) in the right order with the right spices (flags) to make the sausage at the other end. We rely on the cook to remember how they did it the last 10 times and that the taster (functional and ci) says it works. This normally works well but then it turns out that something swapped out somewhere and once 'fully cooked' (composed) that the sausage explodes.
I think we would need to study how the build system really works, and how the recipe of 'order of builds' is determined. From that we can then suggest improvements which the CentOS Release Engineering can implement. It could be that coming up with some tool which makes the order of builds more automated may help, but without knowing how the workplace actually runs.. I am just making suggestions from the restaurant table :).
Cheers,
Alex
> 2. This means rebuilding packages have to wait until that is fixed as
> some people found when they jumped on it sooner. Either they could not
> rebuild anything or when they rebuilt it they needed to do it again when
> the updated packages with the right library links came out.
> 3. Packages in EPEL are maintained by a lot of people who may not know
> that centos-stream have updated rapidly and do not have the spare
> capacity to update sooner than the weekend spare time they had allotted
> to do it.
>
> What are ways that this could be improved?
>
> --
> Stephen J Smoogen.
> Let us be kind to one another, for most of us are fighting a hard
> battle. -- Ian MacClaren
[0]
https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/50_test_comps.sh
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
