12 Scheduling and Dispatching

One of the major functionalities of OBS is to calculate always the current state, based on available sources, binaries and user configurations. In case a change happened it will trigger builds to achieve a clean state again. The calculation of the need of a build job is called scheduling here. The assignment of a build job to a concrete build host (aka worker) is called dispatching.

12.1 Definition of a Build Process

A build process is calculated and executed based on the following

  • The sources of a package defined which dependencies are required at build time. eg. BuildRequires lines in spec files defined which other packages must get installed to build a package

  • The project configuration of the package defines repositories and architectures to build for. In case other repositories are used as a base the configuration from there is also considered.

  • Dependencies of packages which are required are considered as well.

  • Constraints regarding the worker are considered. A package may require certain amount of resources or specific features to build. Check the constraints chapter for details. However, apart from this the build should be independent of the specific worker where the job gets dispatched to.

12.2 Scheduling Strategies

The defaults have the goal of creating an always reproducible state. This may lead to more builds than practically necessary, but ensures that no hidden incompatibilities exist between packages and also that the same state can later be achieved again (with a subsequent rebuild of the same sources and configurations). This can also lead to multiple builds of the same package in the case of dependency loops.

In some setups this may not be wanted, so each repository can be configured in a different way. The usual options to modify the project meta configurations can be used to configure different strategies. For example using osc:

osc meta prj -e YOUR_PROJECT

A repository is configured as following by default, however only the name attribute is required to be set.

# Example <repository
    name="standard" rebuild="transitive" block="all" linkedbuild="off"> [...]

12.2.1 Build Trigger Setting

The build trigger setting can be set via the "rebuild" attribute. Possible settings are


The default behavior, do a clean build of all depending packages


Just build the package with changed sources and direct depending packages. But not indirect depending packages.


Just build packages with changed sources.


Note: You can run into dependency problems in case you select direct or local without noticing this in the build state. Your packages might not even be installable or have random runtime errors (like not starting up or crashing applications), even when they claim to be "succeeded". Also, you cannot be sure that you will be able to re-build them later. So never do an official shipment with this setting of a release. This knob is exposed to allow deliberate suppression of the strictly reproducible builds (for example, to limit burning CPU unnecessarily).

12.2.2 Block Mode

Usually the build of a package gets blocked when a package required to build it is still building at the moment. The "block" attribute can modify this behaviour:


The default behavior, do not start the build if a depending package is currently building.


Just care about packages in your project for the block mode.


Never set a package to blocked.


When using something other than all you will have to deal with the following problems:

  • Intermediate builds can have dependency and runtime problems.

  • Your packages will get built more often, take more resources on the server side. As a result the dispatcher will rate your repository down.

12.2.3 Follow Project Links


DEFAULT: do not build packages from project links


only build project linked packages if they depend on a local package


treat packages from project links like local packages

Print this page