10 Build Configuration

The build configuration is needed at least in each base project to define the setup of the build system. In addition to that it can be used to handle compatibility layers or to switch on or off certain features during the build.

The build config is reachable via API /source/PROJECT/_config, via osc meta prjconf or via webui via Project Config tab.

10.1 Configuration File Syntax

The build configuration is parsed by OBS in rpm style independent of the used packaging format. This means that you can use rpm features like macros or conditions in the configuration. All lines consist of the form 'keyword: arguments'.

<PACKAGES> mean binary package provides, but not the full filename. For example gcc, but not gcc-1.2.3.i386.rpm. Provides of a package can not be used either.

10.1.1 Required: <PACKAGES>

Required lines contain one or more packages that always get installed for package builds. A change in one of the requires packages triggers a new build.

10.1.2 Support: <PACKAGES>

Support lines contain one or more packages which also get installed for package builds, but a change in one of the packages does not trigger an automatic rebuild. This is useful for packages that most likely do not influence the build result, for example 'make', or 'coreutils'.

10.1.3 Preinstall: <PACKAGES>

Preinstall packages are needed to run the package installation program. They get unpacked before the VM gets started. Included scripts are NOT executed during this phase. However these packages will get installed again inside of the VM including script execution.

10.1.4 Keep: <PACKAGES>

To eliminate build cycles the to-be-built package is not installed by default, even when it is required. Keep can be used overwrite this behaviour. It is usually needed for packages like 'make' that are used to build itself. Preinstalled packages are automatically kept, as the package installation program needs to work all the time.

10.1.5 VMInstall: <PACKAGES>

VMInstall is like Preinstall, but these packages get only installed when a virtual machine like XEN or KVM is used for building. Usually packages like 'mount' are listed here.

10.1.6 Runscripts: <PACKAGES>

Runscripts defines the scripts of preinstalled packages which needs to be executed directly after the preinstall phase, before installing the remaining packages.

10.1.7 Order: <PACKAGE_A>:<PACKAGE_B>

The build script takes care about the installation order if they are defined via dependencies inside of the packages. However, there might be dependency loops (reported during setup of the build system) or missing dependencies. The Order statement can be used then to give a hint where to break the loop. <PACKAGE_A> will get installed before <PACKAGE_B>.

10.1.8 ExportFilter: <REGEXP> <ARCHITECTURES>

The export filter can be used to export build results from one architecture to others. This is required when one architecture needs packages from another architector for building. The regexp must match the resulting binary name of the package. It will export it to all listed scheduler architectures. Using a single dot will export it to the architecture which was used to build it. So not using a dot there will filter the package.

10.1.9 PublishFilter: <REGEXP> [<REGEXP> [...]]

The publish filter can be used limit the published binary packages in public repositories. Packages that match any <REGEXP> will not be put into the exported repository. There can be only one line of PublishFilter for historic reasons. However, multiple <REGEXP> can be given.

10.1.10 Prefer: <PACKAGES>

In case multiple packages satisfy a dependency, the OBS system will complain about that situation. This is unlike like most package managing tools, which just pick one of the package. Because one of OBS' goal is to provide reproducible builds, it reports an error in this case instead of chosing a random package. The Prefer: tag lists packages to be preferred in case a choice exists. When the package name is prefixed with a dash, this is treated as a de-prefer.

10.1.11 Prefer: <PACKAGE_A>:<PACKAGES>

It is possible to define the prefer only when one package is creating the choice error. This package must be listed first with a colon.

10.1.12 Ignore: <PACKAGES>

Ignore can be used to break dependencies. This can be usefull to reduce the number of needed packages or to break cyclic dependencies. Be careful with this feature, as breaking dependencies can have surprising results.

10.1.13 Ignore: <PACKAGE_A>:<PACKAGES>

It is possible to define the ignore only for one package. This package must be listed first with a colon.

10.1.14 FileProvides: <FILE> <PACKAGES>

OBS ignores dependendencies to files (instead of package names) by default. This is mostly done to reduce the amount of memory needed, as the package file lists take up a considerable amount of repository meta data. As a workaround, FileProvides can be used to tell the systems which packages contain a file. The File needs to have the full path.

10.1.15 Substitute: <PACKAGE_A> <PACKAGES>

It is possible to replace to BuildRequires with other packages. This will have only an affect on directly BuildRequired packages, not on indirectly required packages.

10.1.16 BuildFlags: <FLAG>:<VALUE>

This defines flags for the build process. The following values for FLAG are usable.

  • vmfstype: Defines a specific filesystem when building inside of a VM.
  • kiwiprofile: builds the selected profile in kiwi appliance builds.

10.1.17 BuildEngine: <ENGINE>

Use an alternative build engine. This is still chained inside of the build script for security reasons. Alternatives are mock (for Fedora and RedHat) and debootstrap (for Debian). This will avoid differences in the build environment setup, but it will also have an effect on speed and reduced features. It should only be used when you want to emulate the distribution build. debbuild enginge will build deb files out of a spec file description. It can be used by the following definition inside of the projet build config:


Repotype: debian
Type: spec
Binarytype: deb
BuildEngine: debbuild
Support: pax
Support: debbuild
Keep: debbuild
           

10.1.18 OptFlags: <TARGET_ARCHITECTURE> <FLAGS>

rpm only: Optflags exports compiler flags to the build. They will only have an effect when the spec file is using $RPM_OPT_FLAGS. The target architecture may be * to affect all architectures.

10.1.19 Type: <TYPE>

Build recepie type. This is the format of the file which provides the build description. This gets usually autodetected, but in some rare cases it can be set here to either one of these: spec, dsc, kiwi, livebuild, arch, preinstallimage

10.1.20 BinaryType: <TYPE>

Binary type. This is the format of the files which will be the result of the build jobs. This gets usually set depending on the build recepie type. In some situations, for example a kiwi build job result gets converted into an rpm, it can be used to overwrite it. Possible values are: rpm, deb or none

10.1.21 Target: <TARGET_ARCHITECTURE>

rpm only: Defines the target architecture. This can be used to build for i686 on i586 schedulers for example.

10.1.22 HostArch: <HOST_ARCHITECTURE>

This is used for cross builds. It defines the host architecture used for building, while the scheduler architecture remains the target architecture.

10.1.23 type: <TYPE>

Defines the recipe format. Valid values are currently: none, spec, dsc, arch, kiwi, preinstallimage. If no type is specified, OBS deduces a type from the binary type.

10.1.24 Binarytype: <TYPE>

(OBS 2.4 or later): Sets the binary format used to setup the build environment. For example a package with spec build description may use and generate deb packages instead of rpms. If no binary type is specifed, OBS deduces it from the recipe type. If the recipe type is also not set, OBS looks at the Preinstall package list for a hint.

10.1.25 Repotype: <TYPE[:OPTIONS]> ...

Defines the repository format for pulished repositories. Valid values are: none, rpm-md, suse, debian, hdlist2, arch, staticlinks. The OPTIONS parameter depends on the repository type, for rpm-md the known options are 'legacy' to create the old rpm-md format, 'deltainfo' or 'prestodelta' to create delta rpm packages, 'rsyncable' to use rsyncable gzip compression. To split the debug packages in an own published repository the option splitdebug:$REPOSIORY_SUFFIX can be used.

10.1.26 Patterntype: <TYPES>

Defines the pattern format. Valid values are: none (default), ymp, comps.

10.1.27 Constraint: <SELECTOR> <STRING>

(OBS 2.4 or later): Define build constraints for build jobs. The selector is a colon-separated list which gets a string assigned. Please see the build job constraints page for details.

10.2 Macro Section

The macro section of the build configuration starts behind a Macros: line and is only used on rpm builds. The content gets exported to be used by rpmbuild during the build. It can be used to export a define using "%key value" lines.

Print this page