30 Multiple Build Description File Handling #

30.1 Overview #

A package source may contain multiple build description files. They can be used depending on the base distribution, the repository name or for different configurations. These mechanics can be also combined.

The right build description file gets picked by filtering. The build will not start when either no file matches or multiple candidates exist. The filtering happens with the following steps:

Based on the package build format of the based distributions. RPM-based distributions will use spec files for example.
Based on the file name of the file before the suffix. It is not important as long as just one file exists, but it has to match when multiple files exist. The name is defined by the build container name, which is either defined in a _multibuild directive file or is the source package name.
Specific files can be created to be built for a specific repository. Append the repository name of the build container behind the package name with a -. For example hello-openSUSE_13.2.spec.

30.2 How Multibuild is Defined #

Use the _multibuild directive to build the same source in the same repository with different flavors. This handy to define all flavors in one place without the need to maintain packages with local links. This allows also to transfer all sources including a possible changed flavor from one project to another with a standard copy or submit request.

The _multibuild file lists all build container names, each of them will be built as usual for each defined repository and each scheduler architecture.

For example, inside the kernel source package we can build both kernel-source and kernel-obs-build packages by listing them inside the file.

Multibuild packages are defined with the _multibuild directive file in the package sources.

The _multibuild file is an xml file. For example:

<multibuild>
  <flavor>kernel-source</flavor>
  <flavor>kernel-obs-build</flavor>
</multibuild>

Build description files are needed for each of them for each package (for example, kernel-source.spec or kernel-obs-build.dsc) inside of the sources. There will be another build in case there is also a matching file for the source package container name, otherwise it will turn into an “excluded” state. Dockerfile based build descriptions may provide own build descriptions for each flavor via Dockerfile.FLAVOR suffixed files.