mpb.config - Man Page

The mass-prebuilder configuration file is written in YAML. By default, mpb will look for configuration files in the following order:

1. Any file provided through the --config argument
2. A mpb.config file in the current directory
3. ${HOME}/.mpb/config

If any of these is found, it is read and the others are ignored.

At its simplest, the configuration only provides the list of main packages to be built:

packages:
  autoconf:
    src_type: file
    src: /path/to/autoconf.src.rpm

This will create a mass build around autoconf, on Fedora rawhide for the x86_64 architecture. The list of packages that depend on autoconf and need to be rebuild is computed automatically.

All the available configuration options, the default and accepted values are detailed in /usr/share/doc/mass-prebuild/examples/mpb.config.yaml.

The mass-prebuilder comes with multiple back-ends which have different set of capabilities.

copr is the original back-end, the one that is recommended in most situations. It provides flexibility in term of architecture and distributions, and even allow to rebuild a failed package while providing an SSH access to the builder if needed. This back-end as similar requirements as the copr-cli tool in term of credentials and accesses.

mock allows to build the packages on your local machine. This may be handy when debugging the build failure is needed. There are some limitations in term of flexibility. Currently not all state can be cleaned up correctly if the python sub-process is terminated manually during the mbp build. It is therefore recommended to either let the process run until the end, or demonize it (and let it run).

remote_mock uses similar features as the mock backend, through SSH. Similar limitations to the mock backend are to be expected, moreover if the connection isn’t stable.

koji make use of the Koji build infrastructure notably available for distributions like Fedora. This back-end provides limited features compared to copr. Among the limitations:

• file source type can’t be used for the main packages. Koji is an official builder, and builds that generates usable artifacts may only be generated from dist-git. This limitation doesn’t apply to the reverse dependencies as they are built using the scratch build feature of Koji.
• Since the main package is built using the draft feature, all necessary changes must be available in dist-git, and the NEVRA must have been updated.
• For the same reason, this back-end can’t be used to rebuild a package with a NEVRA that has been consumed. Yet, one may use the deps_only option which will make mpb aware that a build is already available for the main package.

The koji back-end needs credential to be set up through kinit. Other login methods aren’t supported.

In order to compute the list of packages that depend on the main packages, mpb looks at distribution repositories and interrogates Koji servers about latest build-able version of these packages.

Default repository configurations are available in /etc/mpb/repo.conf.d/. They are superseded by configuration files available in ${HOME}/.mpb/repos.conf.d.

Although mpb could use the system provided repository files, this would limit its capabilities, since it may need to request information for a foreign distribution, or simply a different version. Thus, one may provide customized information, for mpb to do the package computation.

The configuration file is written in YAML, and few examples are available in /usr/share/doc/mass-prebuild/examples/repos.conf.d.

Note that these files are named against the distribution they refer to by convention, only the content of it is important.

The structure of the file is the following:

distribution: # The name of the distribution, e.g. fedora
  release: # The name of the release, e.g. rawhide
    koji: https://my.kojiserver.org/kojihub # Address to the kojihub to request for latest version of a package
    base: https://thebase.ofmyrepository.org/
    src-repos:
    - BaseOS/source/os/ # Any path to be concatenated to base
    bin-repos:
    - BaseOS/{}/os/ # Any path to be concatenated to base, {} will be replaced by the architecture

If the release isn’t given (i.e. Everything else moves one level up), then the values provided will be used as default for the distribution. An example for that behavior is given with /usr/share/doc/mass-prebuild/examples/repos.conf.d/fedora.yaml