22 OBS Concepts #

A project is configured in the project /source/$PROJECT/_meta path. It can be edited in the web interface using the RAW Config tab or via command line with

osc meta prj -e $PROJECT

This file contains:

The following flags can be used to control the behavior of a package or project. Most of them can also be limited to specified repositories or architectures.

A project is configured in the project /source/$PROJECT/_config path. It can be edited in web interface in the Project Config tab or via one of the following command lines

osc meta prjconf -e $PROJECT
osc co $PROJECT _project

The build configuration is used to tell the OBS how to set up the build environment, and is explained in Chapter 4, Build Configuration.

The macro configuration is part of the build configuration in /source/$PROJECT/_config. It can be added at the end after a Macros: line.

The build configuration is used to tell the OBS how to set up the build environment, and is explained in Chapter 4, Build Configuration. Within that chapter, build macros are explained in Section 4.4, “Macro Definitions in the Build Configuration”.

An OBS Package is a sub-namespace below a project. It contains the specification of a single package build for all specified repositories.

In a DoD repository external software repositories can be configured which are used for dependency resolution and where packages will be downloaded at build time. A DoD repository has some main advantages in comparison to binary import projects:

In download repotypes where package checksums can be verified (e.g. susetags, rpmmd and deb), we recommend that you use a mirror server URL in <download> in order to reduce traffic on the master server and configure a <master> with an https url and a sslfingerprint in order to avoid man in the middle attacks by peer verification.

The bs_dodup daemon periodically checks for new metadata in remote repositories. This daemon can be enabled for startup with the command

systemctl enable obsdodup.service

and can be started with

systemctl start obsdodup.service

mandatory attributes:

The <master> tag as shown in the rpmmd example below is optional but strongly recommended for security reasons.

Verification is supported in the following repotypes

This option could be defined by any valid URL (HTTP and HTTPS) to the origin of the repository but it is strongly recommended to use https with a sslfingerprint to bs_dodup possibility to verify its peer in order to avoid man-in-the-middle attacks. The download URL can be a mirror as we validate package checksums found in repo data.

You can easily query the SSL fingerprint of a remote server with the following command:

openssl s_client -connect <host>:<port> < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout

The pubkey element contains one or more GPG public keys in order to verify repository information but not packages. For an example, look at the repotype "deb" documentation below.

This chapter makes some recommendations how upstream resources can be integrated into the build process. SCM stands for source control management. git, subversion or CVS are concrete implementations of an SCM. The OBS itself comes also with an own SCM, but this is only intended to manage the files needed for packaging. However, you can add references to external SCM systems. The source service system will mirror the sources and provide it to the build systems. OBS makes sure that you can access the sources of all builds also in the future, even when the upstream server delivers different or no content at all anymore. Using external SCM references has the following advantages:

External references are defined in _service files. The file can look like this:

<services>
  <service name="obs_scm">
    <param name="url">git://...</param>
    <param name="scm">git</param>
  </service>
  <service name="tar" mode="buildtime"/>
  <service name="recompress" mode="buildtime">
    <param name="file">*.tar</param>
    <param name="compression">xz</param>
  </service>
  <service name="set_version" mode="buildtime" />
</services>

The services do the following:

Note that only the first service (obs_scm) runs on the OBS server. The other services run during the build process. They can also be replaced by any user by providing alternative implementations of them, or by writing their own service from scratch.

Using osc build in any package with such a definition will do the same process locally. The only difference is that you get a local subdirectory with the SCM content. You can go inside and work as you are used to. Any changes inside will be used for your next local build, whether they were pushed to the upstream server or not. However, you need to push it upstream when you let the OBS server re-fetch the changes from upstream. The only way out would be to set the obs_scm service to mode disabled and upload your local archive.

The obs_scm service allows you to export files next to the archive. You can specify one or more files using the extract parameter. Use it for your build recipe files.