productcomposer

1. Goals

A lightweight successor for 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 currently not taking care of dependencies.
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 types of RPM meta data generation

Not yet implemented: - create bootable iso files

2. Design

product composer is supposed 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.2
vendor: I_and_myself
name: my_product
version: 1.0
product-type: module

architectures: [ x86_64 ]

packages:
 - my-single-rpm-package

5.2. build options

The build options may be used to change the behaviour of the build process. The options are described in the details below.

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

5.3. 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.4. iso

Enables iso file generation and requires configuration of iso9660 headers.

5.5. content

content defines the packagesets to be used as entry point for the medium.

The default is just to use the "main" packageset.

5.6. unpack

unpack defines the packagesets to be used for extracting the content of the rpm packages directly on the medium.

These rpm packages need to provide these files below

/usr/lib/skelcd/CD1

Currently it gets only extracted to the first/main medium, but not on source or debug media.

5.7. packagesets

The packagesets definitions. A packageset 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.

The packageset requires at least a packages definition, but may optionaly also a name, flavors or architectures.

5.7.1. name

Defines the name of the package set. main is the default name.

5.7.2. architecture

Lists the architectures where the set is to be used. The default is for all architectures.

5.7.3. flavor

Lists the flavors where the set is to be used. The default is for all flavors.

5.7.4. add

Can be used to add further packagesets by specifing their names.

A special packageset called all will add all package names local available.

5.7.5. sub

Can be used to remove packages from the specified packageset names.

5.7.6. intersect

Can be used to filter packages with specified package set lists.

5.7.7. packages

Lists all package names to be added. This is just the rpm name, not the file name.

5.7.8. supportstatus

Define support status level for the packages listed in packages. Valid support levels are l3, l2, unsupported. However these are handled as strings. If the string starts with a "=", it overrides any previously set support status from inherited package sets.

5.8. Details

5.8.1. name

The product name.

5.8.2. version

The product version

5.8.3. update

Optional update level string for CPE

5.8.4. edition

Optional edition string for CPE

5.8.5. summary

The product name in explaining words. It will be presented to the user on overview screens

5.8.6. product-type

Either base for operation systems or module for any product depending on any existing installation.

extension is handled as alias for module.

5.8.7. 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.8.8. bcntsynctag

Optionaly defines a bcntsynctag for OBS. OBS will sync the build counter over all packages in same repository and architecture according to this tag.

5.8.9. milestone

Optionaly defines a milestone which will be used by OBS at release time. This can be used to turn candidate builds into a Beta1 for example

5.8.10. build_options

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.

OBS_unordered_product_repos

OBS is by default filtering rpm packages based on the repository path layering.

This switch can be used to disable this behaviour in cases where a binary from a lower priorisated repository should be used.

This can increase the amount of required binaries a lot when dealing with deep path lists.

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.

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.

add_slsa_provenance

Add slsa provenance files for each rpm if available

abort_on_empty_updateinfo

Existing updateinfo.xml are scanned by default and reduced to the available package binaries. In case none are found the update is skipped. Enableing this option leads to a build failure instead.

skip_updateinfos

No updateinfo meta information is added to the media. This might be required when not using take_all_available_versions, but building on a former released code base.

updateinfo_packages_only

Build a pure update repository. Skipping all matching rpms which are not referenced via an updateinfo.

base_skip_packages

Controls whether packages should be copied in the /install directory when using base iso images.

Enabling this would result in a simply repacked base image, without any package copied there.

5.8.11. iso

publisher

For setting the iso9660 PUBLISHER header

vendor_id

For setting the iso9660 VENDOR_ID header

tree

Can be set to "drop" for creating only the iso files.

base

Can be used to copy the result into a pre generated iso file. product-composer itself is not creating bootable iso images, aka installer images. But it can used for example to use iso images with the agama-installer where it copies the main tree inside.

When defining a base iso name, it is expected that: * the image gets provided via an rpm called baseiso-NAME * the image is available in the /usr/libexec/base-isos directory with the given NAME prefix.

product-composer will add the main product tree into /install directory of this media. The build result will be a single iso file name with the product name and a .install.iso suffix.

Only a single repository per product is usable. In case source or debug rpm’s need to be added, they need to be part of the main repository.

5.8.12. installcheck

Runs a repository closure test for each architecture. This will report any missing dependencies and abort.

ignore_errors

For reporting the dependency errors, but ignoring them.

5.8.13. debug

Configure the handling of debuginfo and debugsource rpms. Use either

debug: include

to include them or

debug: drop

to drop all debug packages or

debug: split

to create a seperate medium mwith -Debug suffix.

Missing debug packages will always be ignored.

This default setting may get specified per flavor.

5.8.14. 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.8.15. product_compose_schema

Defines the level of the yaml syntax. Please expect incompatible changes at any time atm.

This will be used to provide backward compability once we stabilized.

5.8.16. 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.8.17. source

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

source: include

to include all source packages or

source: drop

to drop 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.

This default setting may get specified per flavor.

5.8.18. repodata

Write architecture specific repository meta data into the architecture specific sub directories. This way a client needs to process less data. The disadvantage is that different URL’s need to be handled per architecture.

repodata: split

It is also possible to have a main repodata including all architectures in addition to the architecture splitted ones.

repodata: all

In absence of the repodata element only the main repodata is created and includes all architectures.

This may get specified per flavor.

5.8.19. vendor

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

5.8.20. set_updateinfo_from

Can be set to replace the "from" attribute in updateinfo.xml files with a fixed value. This is shown as patch provider by zypp stack. Otherwise the value stays, OBS is setting the packager from _patchinfo file here by default.

5.8.21. set_updateinfo_id_prefix

Sets a fixed prefix to all id’s of included updateinfo data. It is not adding again if the prefix exists already.

This can be used to have a common identifier for an update for many products, but still being able to identify the filtering for a specific product.

5.8.22. block_updates_under_embargo

The current default is to include maintenance updates under embargo. This option can be set to abort when an embargo date is in future.