Kevin Fenzi wrote:
>> Something needs to be done to make the compose process more robust, e.g.:
>> * running createrepo on a stable release, so that we do not have to be
>> able
>> to init a chroot of the target system to compose a repository. A broken
>> dependency, even in systemd or rpm, should NEVER be a reason for the
>> repository to fail to compose.
>> * publishing individual deliverables one at a time, i.e.:
>> 1. compose the repositories,
>> 2. sync the repositories out to the mirrors,
>> 3. build the images (atomic ostrees, live images etc.) one at a time,
>> 4. sync those images that succeeded out to the mirrors, keep the old
>> versions of the other ones (the matching SRPMs are in Koji anyway,
>> so it does not matter if the SRPMs in the tree don't match)
>> etc.
>
> I disagree entirely with the above. I think the solution is to gate
> packages coming into rawhide and hold or reject those that break the
> compose until they are fixed. I think being proactive is VASTLY better
> than being reactive. Not breaking something in the first place is much
> easier to deal with than trying to fix it later.
And how do you propose doing that? The only reliable way to hold packages
that break the compose would be to actually try to run the whole compose
process after every package build. That just does not scale. The composes
are only daily for a reason. Running a compose for every package build would
use a lot of resources and would also take very long, delaying the tagging
of the package into Rawhide for an insane amount of time (at least hours).
If you propose just doing some fast automated tests catching some issues,
that will never reliably catch all issues breaking the composes, and so my
proposals to increase the robustness of the compose process will still be
relevant. The only way to know for sure whether the compose will succeed is
to run it (and even that will not necessarily catch non-deterministic
failures).
It is just defensive programming to not fail the whole process on any small
issue that you cannot avoid (with the resources that are available).
By the way, in the distant past, if some (or even all) live image compose(s)
failed, the compose would just get published without that/those live
image(s) (in the worst case, with an empty Live directory). Not ideal (and
keeping the last successful build of each image as I suggest doing would be
an improvement on that, Koji should be enough to fulfill the copyleft
licenses' source distribution requirements), but at least the package repo
went out a lot more often than nowadays.
>> Right now, e.g., we have a known broken GCC (8.0.1-0.14) in the Rawhide
>> and Branched trees (which miscompiles the Chromium/QtWebEngine build tool
>> GN on x86_64), the fix (8.0.1-0.16) has already been in the right Koji
>> tags for days, but any third-party repository (RPM Fusion, Copr, etc.)
>> will still get the broken GCC. This is not acceptable.
>
> I'm sure there's any number of bugs in any number of collections of
> packages.
I am not asking you to ship bug-free composes. (I know that's impossible.
;-) ) I am just asking you to take less than a week to get a compose with an
already built critical fix out. :-)
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
