1. Goals

A lightweight success or product builder.

It is used to generate product rpm repositories out of a pool of rpms. Unlike product builder, these can also be used to ship maintenance updates.

Currently it supports:

  • processing based on a list of rpm package names. product compose is not take care of dependencies atm.

  • providing matching source and/or debug packages for picked rpm packages. These can be either included into main repository or prepared via extra repositories

  • optional filters for architectures, versions and flavors can be defined

  • it can provide either just a single rpm of a given name or all of them

  • it can post process updateinfo data

  • post processing to provide various rpm meta data generation

Not yet implemented: - create bootable iso files

2. Design

product composer issupposed to be used only inside of OBS builds atm. OBS or osc is preparing all binary rpm candidates in local directory before starting the build.

3. Setup in OBS

You will require OBS 2.11 or later.

Create a new repository with any name. Either in a new or existing project.

  • The product-composer package must be available in any repository listed in the path elements.

  • All scheduler architectures where packages are taken from must be listed.

Your build description file may have any name, but must have a .productcompose suffix.

The build type for the repository must be set to

Type: productcompose

in the build configuration (aka prjconf).

4. Special setup for maintenance

Ensure to build your patchinfo builds in a repository where "local" is the first architecture.

Your productcompose file may provide all versions of each rpm if you enable "take_all_available_versions" in the build options.

5. productcompose build description options

5.1. minimal version

product_compose_schema: 0
vendor: I_and_myself
name: my_product
version: 1.0
architectures: [ x86_64 ]
packages:
 - my-single-rpm-package

5.2. build options

5.2.1. take_all_available_versions

By default only "the best" version of each rpm is taken. Use this switch to put all candidates on the medium. For example for maintenance repositories.

5.2.2. ignore_missing_packages

Missing packages lead by default to a build failure. Use this switch to continue. The missing packages are still listed in the build log.

5.2.3. hide_flavor_in_product_directory_name

The flavor name is by default part of the directory name of the build result. This can be disabled, when each flavor has a different arch list. Otherwise conflicts can happen.

5.2.4. flavors

Flavors can be defined with any name. These can be used to build multiple media from one build description.

Each flavor may define an own architecture list.

It can also be used to add different package sets.

You need to add a _multibuild file to your sources to enable the build.

5.2.5. packages

The packages list lists rpm names to be put on the medium.

There is usually one master list and in addition there can be addional optional lists.

The additional lists can be filtered by flavors and/or architectures.

5.2.6. unpack_packages

The unpack_packages section can be used in the same way as the packages section.

The difference is that not the rpm itself is put on the medium, but the extracted content only.

5.3. Details

5.3.1. name

The product name.

5.3.2. version

The product version

5.3.3. architectures

An array of the master architectures to be put into the repository. This can be used to build a single repository usable for many hardware architectures.

product composer will automatically fall back to "noarch" packages if the package is not found natively.

Setting a global architecture list is optional, when architectures are listed for each flavor.

5.3.4. build_options

The build options may be used to change the behaviour of the build process. The options are described above.

Just add them to enable them, no further arguments are allowed.

5.3.5. debug

Configure the handling of debuginfo and debugsource rpms. Use either

debug: drop

to exclude them or

debug: split

to create a seperate medium mwith -Debug suffix.

Missing debug packages will always be ignored.

5.3.6. packages

The package list. It can contain either simple name or it can be extended by a >, >=, =, <, ⇐ operator to specify a specific version constraint.

The syntax for the version is rpm like

[EPOCH:]VERSION[-RELEASE]

A missing epoch means epoch zero. If the release is missing, it matches any release.

The package list can be valid globally or limited to specific flavors or architectures.

5.3.7. product_compose_schema

Defines the level of the yaml syntax. We are currently at level 0. Please expect incompatible changes at any time atm.

This to used to provide backward compability.

5.3.8. product_directory_name

Can be used to specify a directory or medium name manually. The default is "name-version".

The directory name will always be suffixed by the architecture and build number.

5.3.9. source

Configure the handling of src or nosrc rpms for the picked binaries. Use either

source: drop

to exclude all source packages or

source: split

to create a seperate medium with -Source suffix.

A missing source package leads to a build failure unless the ignore_missing_packages built option is used.

5.3.10. vendor

Defines the company responsible for the content. Can be for example openSUSE or SUSE. It is used by the install stack.