Build Service/prjconf

From openSUSE

Description

The prjconf denotes the (build) configuration of a Project. The main part of this file (/usr/lib/build/configs/$distro.conf) is the definition of the build environment. For simple projects, it may well be empty. But everything that normaly needs a user decision (like packages providing the same stuff) or special macros/packages/flags in the build environment is defined here.

The syntax is basically the same as in rpm spec files, just the tags are different. Conditionaly like %if, %ifarch etc also work.

Currently, the webfrontend doesn't support editing the Project config. But you can use osc for this:

Have a look at project config of the openSUSE:Factory project to get an impression about what is possible.

The default package list for a build environment is: Preinstall + Required + Support + Packages from dependency expansion.

Supported Tags

Preinstall

The packages that need to be unpacked for build environment setup. This is basically everything that is needed to get rpm/dpkg running, i.e. glibc and the like.

Preinstall: filesystem fillup glibc

"Install" the filesystem package in the chroot environment, so rpm/dpkg can work.

Runscripts

A subset of the preinstall packages. It describes which packages need to have their postinstall scripts run.

Runscripts: aaa_base

Required

These are the packages that make the "normal" build environment, i.e. stuff like gcc, autoconf, automake and the like.

Required: autoconf automake binutils

Install autoconf in the build environment - this is done via the normal packagemanager (rpm/dpkg).

Support

Convenience packages, like "vim" or "strace". The difference to "Required" is that the automatic rebuild detection does not look at support packages, i.e. you don't get an automatic rebuild if "strace" is changed.

This list also includes some "-devel" packages and other subpackages of the "Required" packages to keep the Required list small. (I.e. we don't need both "zlib" and "zlib-devel" in Required because both are built from the same source).

Support: vim strace glibc-devel

Keep

We really need those packages. Normally, subpackages of the package that we want to build don't get installed. But even if we want to build the "patch" package, we need a working patch program to apply patches from the specfile. So we have "Keep: patch". The preinstalled packages are automatically added to this list.

Keep: gdbm glibc-devel glibc-locale

Prefer

This information is used to break ambiguities.

Ignoring a package:

Prefer: -suse-build-key

Choosing a package:

Prefer: openSUSE-build-key 

This can also be done on package level:

Prefer: tomboy:gconf-sharp

For package tomboy, choose gconf-sharp.

This can also be done on package level in specfile via "BuildRequires" / "#!BuildIgnores": BuildRequires: openSUSE-Build-key #!BuildIfnore: suse-build-key

Substitute

Packages get renamed or are named different for different distributions. You can specify per repository dependency rewrite rules.

%if 0%{?suse_version}
Substitute: Canna-libs canna-libs
%endif
%if 0%{?fedora_version}
Substitute: canna-libs Canna-libs
%endif

On openSUSE, the package is named "canna-libs", so replace all requirements for "Canna-libs" to "canna-libs" - and vice versa for Fedora.

Ignore

This breaks dependencies for the package expansion step. Means that we don't need an installed package if another package normally needs (Requires) it.

Ignore: portmap:syslogd

We don't need an installed syslogd if we have to install the portmap package.

This is also possible on package level: by adding "#!BuildIgnore" lines to the specfile: #!BuildIgnore: syslogd

ExportFilter

Copy build binary package from one arch to another. This is mostly needed for packages only available on one architecture, but needed on other archs which can at least emulate the package arch.

ExportFilter: ^wine.*\.i586.rpm$ . x86_64

Copy the build wine package from the i586 architecture to x86_64.

Order

Some distributions might have problems during the chroot-setup - manual intervention is needed. With this "Order"-Tag, you can specify an installation order.

Order: libopenssl0_9_8:openssl-certs

If openssl-certs needs to be installed, install libopenssl0_9_8 first.

VMinstall

Like Support: add these packages if you're "building" in a virtual machine.

VMinstall: util-linux perl-base libdb-4_5 libvolume_id1 libsepol1

Optflags

Default compiler flags. (Can be overwritten by specfile.)

Optflags: i586 -march=i586 -mtune=i686 -fmessage-length=0

Macros

Macros are defined at the end of the prjconf to avoid missinterpretation.

Two options of Macro definitions are possible in the prjconf file:

1. Macro definition lines starting with %define are used inside the prjconf itself and for calculating the build dependencies of spec files. They are not available inside the build root.
2. Macro definitions after the Macros: are exported into the .rpmmacros file of the user used for building the package inside the build enviroment. Ie those are available for general use use in a spec file.

%define Tag

Use %define as usual with rpm. Full rpm syntax is supported in principle except for functions. Macros that call an external command cannot work of course and are therefore not supported either.

%define _with_pulseaudio 1

Defines a Macro %{_with_pulseaudio} with value 1. Useful for example to enable pulseaudio in your project if the .spec file uses the following construct to enable conditional build:

 %bcond_with pulseaudio
 %if %{with pulseaudio}
 BuildRequires: pulseaudio-devel
 %endif

Macros after the Macros:-Tag

A line

Macros:

at the end of the prjconf starts a block of macro definitions that are exported into the build environment. You can basically define anything here, including macros that are functions or call external commands since those macros are actually evaluated by rpmbuild. The define statement is implicit here so just start with %macroname.

To stay with the simple example above, to not only tell the build service to install the pulseaudio-devel package but also have rpmbuild know to build with pulseaudio the following definition needs to be in the macro block as well:

%_with_pulseaudio 1

Currently, those macro definitions can only be added at the end of the prjconf.