On Fri, 6 Oct 2023 at 15:45, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
On Fri, Oct 06, 2023 at 11:16:17AM -0400, Stephen Gallagher wrote:
> So, as we all know, build ordering is hard (and, despite intuitive
> belief, not actually deterministic).
>
> ELN actually "cheats" somewhat when we do our builds. When we process
> a batch of builds (triggered by a set of tag events that come in all
> at the same time, such as when a side-tag is merged), we create a new
> ELN side-tag, tag all of the new *Rawhide* builds into this side tag,
> then trigger a rebuild of all of those builds for ELN. The result here
> is that we use the Fedora build in the buildroot to avoid
> bootstrapping issues. Now, there are some special-case packages for
> which we do *NOT* automatically tag in the Fedora builds because they
> have known incompatibilities. All OCAML packages fall into this
> category, since we discovered about 9 months ago that we absolutely
> cannot mix Fedora's OCAML builds with ELN's (I don't recall the exact
> reason).
It's probably because the build flags are different and
(unnecessarily) OCaml encodes the build flags into the hashes of one
of the base modules. I forget the exact details but there's an email
on this list about it somewhere. Anyway the upshot is that if the
build flags change at all, as they obviously do in Fedora vs RHEL,
then the hashes change. We ought to fix this upstream ...
Anyway I was going to say why not order the packages by their original
build date in Koji?
Mass rebuilds and multiple developers can make this much harder than expected. The history looks linear, but it may be that the bootstrap blew up and had to be restarted OR it does need to do a double loop. Or developer A rebuilt something when it wasn't needed while B was doing something in a side tag at the same time. Or you find that rust or go needed to have old/new mixes which weren't needed last time because ordering didn't matter that time but does now (this can be due to flags or package differences.) Many of these things are things which the regular package maintainers know to do with their pets, but other people do not.
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
