Module build order

Packages which are built within a module stream can have dependency relationships between them. This means that packages within a module can use other packages from the same module as build or runtime dependencies. For this to be possible we are using the buildorder property which can be added to each of the components defined in a module stream.

By default, if no buildorder property is specified the build order of the packages is equal to 0 for the purposes of the module stream build. This means that all the packages can be built at the same time.

If the buildorder property is specified for each component of the module stream, the build system needs to respect this ordering. This means that each buildorder number represents a group or a batch of packages that need to be built together. Each higher “build batch” needs the RPM artifacts from the previous build batches to be present and enabled in the current one. So they can serve as dependencies for the current batch. This continues until the last batch is built. The last batch will contain all the other artifacts from the previous batches.

build order of a perl-bootstrap:5.32 module stream
⋮
components:
        rpms:
            perl:
                rationale: The Perl interpreter.
                ref: f33
                buildorder: 0
            perl-Fedora-VSP:
                rationale: A build dependency.
                ref: f33
                buildorder: 1
            perl-generators:
                rationale: A build dependency.
                ref: f33
                buildorder: 2
            perl-Algorithm-Diff:
                rationale: A build dependency.
                ref: f33
                buildorder: 3
            ⋮
            perl-Config-AutoConf:
                rationale: A build dependency.
                ref: f33
                buildorder: 4
            ⋮
            perl-IO-Compress-Lzma:
                rationale: A build dependency.
                ref: f33
                buildorder: 5
            ⋮
            perl-Data-OptList:
                rationale: A build dependency.
                ref: f33
                buildorder: 6
            ⋮
            perl-Sub-Exporter:
                rationale: A build dependency.
                ref: f33
                buildorder: 7
            perl-Data-Section:
                rationale: A build dependency.
                ref: f33
                buildorder: 8
            perl-Software-License:
                rationale: A build dependency.
                ref: f33
                buildorder: 9
⋮

In this example we have the build order of the perl-bootstrap:5.32 module. The component with the lowest buildorder number will start building first. In our case this is the package perl with the buildorder number 0. All the other component (package) builds need to wait until the first build batch is built. A build batch consists of packages which share the same buildorder number. After the perl package is built then the build batch has finished building all its components and can move to a higher order of the build order. The build of package perl needs to be added and enabled to the buildroot of the build of packages of the next buildorder number. In our case the next build batch is the build batch with the buildorder number 2. A build batch can have one or more packages. This means that the packages can be built simultaneously. Each build batch uses all the previous build batches as build dependencies which are available and enabled in its buildroots. The only build batch which does not have any previous build batch dependencies is the build batch with buildorder number 0. The only build batch which is not used as build batch dependencies is the build batch with the highest buildorder number. In our example the build batch with buildorder number 5 consists of 9 packages and number 4 consists of over 100 packages. All the packages built in build batches of buildorder numbers 0-4 will be used as build time dependencies for the build batch with the buildorder number 5.