Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]

3 Build Process

Each package build is created in a fresh environment. This is done to ensure that all dependencies are available and that every later build produces identical results.

3.1 Phases of a Build Process

All sources and binaries which are hosted inside Open Build Service are organized in projects. Projects host sources inside of OBS packages. The sources are build according to the repository configuration inside of the project.

3.1.1 Preinstall Phase

This phase depends on the type of the buildroot (building environment). OBS supports three different types of buildroots:

  • chroot

  • Xen

  • KVM

In the preinstall phase, the OBS Worker creates a small base system (chroot or VM Image) with manually extracted packages (file system, coreutils, binutils, rpm/debutils, etc.), copies all necessary build requirements into the base system.

3.1.2 Install Phase

Depending on the chosen build root, the worker starts a Xen or KVM virtual machine or enters the build root. If this was successful, the install phase reinstalls all base packages from above and additionally all packages you have defined in your build recipe. After this phase the environment is ready to process the build recipe.

3.1.3 Package Build

Depending on the type of package, the buildroot executes different build commands:

  • RPM-based distributions: rpmbuild

  • Debian-based distributions: dpkg-buildpackage

  • Arch Linux: pacman.

How the build continues depends on the quality and the type of your build recipe. In most cases, the source code will be compiled now and then be packed into the chosen package format.

To improve package quality, on RPM-based distributions there are additional security checks and a linter called rpmlint.

3.1.4 After the Build

The generated packages are taken from the worker, are signed by the OBS signer and are published to the Repository.

3.2 Identify a build

OBS is usally tagging each build with an identifier. This can be used to find the building OBS instance, the project, repository and exact source for a binary. This information is stored in some variable called DISTURL and is specified as obs://$OBS_INSTANCE/$PROJECT/$REPOSITORY/$SOURCE_REVISION-$PACKAGE(:$FLAVOR) . Note that the last $:FLAVOR part is optional and exists only when the package was build using the multibuild feature. The source specified via the DISTURL can be accessed by pasting the URL into the search interface of the OBS web interface. Or use the command line tool to check it out:

     # osc checkout $DISTURL

You need to go to the right OBS instance as this is not handled automatically yet.

3.2.1 Read DISTURL from a rpm

Rpm binaries contain the DISTURL as tag. It can be read from the rpm database for installed rpms and also from the rpm binaries itself.

     # rpm -q --qf '%{DISTRL}\n' $rpm

3.2.2 Read DISTURL from a container

Containers store the DISTURL as label. You will see only the DISTURL from the highest layer via

     # docker inspect --format '{{.Config.Labels}}' $image_id

The disturl is always set via the key 'org.openbuildservice.disturl'.

Print this page