fm-orchestrator

#715 [RFE] Automatically determine buildorder
Opened by sgallagh. Modified

Open
Close Issue

@psabata and I have discussed this a few times on the public IRC channel, but I was thinking about it some more this morning and I wanted to get my thoughts down in a ticket.

What I'd like to see in MBS is the ability for it to follow roughly the following algorithm:

  1. $buildorder = 0 (unspecified == 0)
  2. Build all packages listed in $buildorder
  3. All failures are assigned to $buildorder+1 except those that are blacklisted (see below)
  4. If the $buildorder +1 is empty, the build succeeds and terminates.
  5. If the $buildorder+1 list is identical to the $buildorder list, the build fails and terminates.
  6. $buildorder = $buildorder + 1
  7. GOTO 2.

On success, the final buildorder values that allowed all the packages to succeed will be reported back to the user, so the modulemd YAML can be updated (this might also be automated, but that's out of scope for this ticket).

This will allow users to submit a module the first time and let MBS figure out the complexities of the buildorder values. Unlike the original version I discussed with @psabata, this will also handle cases where a dependency ordering changes out from under the module owner. The build will still succeed and they will be told what values to adjust so that their subsequent builds will complete faster.

Pros:

  • Significantly reduces the effort necessary to maintain a module. The user really only needs to know which packages they want in the module and doesn't have to do complicated dependency analysis to figure out the build order.

Cons:

  • The first build of the module may take a long time. The worst-case being when the build of every package in the module is dependent upon exactly one other package in the set.
  • Runs of the build where a package is failing to build for reasons other than a dependency will end up going through N+1 attempts to build that package, where N is the number of needed buildorder stages. This can probably be mitigated somewhat by having failures check to see if the failure occurred in root.log, which would indicate that the problem was definitely due to missing buildrequires. We could then opt to just treat it as failed immediately for any other build error, rather than trying to figure out the order.
  • Some packages may take an extremely long time to build (kernel, gcc, etc.). For this, I recommend that we add another option to the component section of the modulemd YAML to allow us to blacklist this package from automatic buildorder determination.

I always imagined this like some extra endpoint which would build a module like you describe and as a result, it would give you the modulemd with buildorder with which the module build succeeded. You would then review that, commit it to your repo and build it.

I don't see a way how this could be done everytime on every build you submit.

Note that I also think this could easily be external tool just calling MBS and reading the info about failed builds.

I would like to make some note that you don't need to check whether it fails or not, you just need to try resolve dependencies... because otherwise it could take ages.

So let me explain how OBS does this.. It has concept of few states:
* unresolvable
* failed
* building
* succeeded

so unresolvable means that dependencies are not satisfied.. I think MBS could do something like this.. But please don't rely on failing builds from koji/copr.. It is slow and unreliable.

@ngompa can correct me about OBS implementation.

Corresponding issue in fedmod looking at the question of how to derive a plausible build order based on declared build requirements: https://pagure.io/modularity/fedmod/issue/48

I think we need that buildorder only in one place, preferably in MBS as that's where all the modules need to pass through.

Buildorder in fedmod can only be a short term solution until MBS gains this ability.

Anything that relies on failing builds works slightly badly for the Flatpak use case.

In the Flatpak use case, we are taking applications and their library dependencies from the main Fedora package set, and rebuilding them with prefix=/app. All the build requirements will already be in the main package set, so likely any build order will succeed.

But the application (or libraries) may end up being build against the -devel packages from the main package rather than the new rebuild -devel packages. 99% of the time this is OK. An example of where it wouldn't work would be, if hypothetically the gdk-pixbuf and librsvg2 were included in the module, then librsvg2 would do:

pkg-config --variable=gdk_pixbuf_moduledir gdk-pixbuf-2.0

And install it's image format loader in the wrong place if built before gdk-pixbuf-2.0. (gdk-pixbuf and librsvg will actually be in the runtime, so not end up in Flatpak modules, but this shows a potential type of problem.)

And even if no problems show up, you won't end up with a sensible build order in any case.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/mbs/issues/715

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.