openSUSE:Build Service Concept Product Definition
Product definition
The purpose of the Product Definition is to collect all needed information to be able to build a product in one place. A product is a defined set of packages plus extra information. A product can be a complete operating system or an extension (called Add-On) for another one. The same product may get delivered in various forms (call "flavors").
Examples for a product are the "openSUSE 11.1" distribution, which comes on a DVD5, DVD9 or FTP network installation. Also the Add-On medias for additional language support or the non-free extensions are products.
All these products and their flavors are described as a product via the product definition.
Content of product definition
The product definition needs to specify the following kinds of information to allow the Build Service to build a medias from it.
General product information
General product information are the kind of information which are the same for all flavors and across all hardware architectures. These are for example the product name, version and its current development state (Alpha, Beta or RC version).
The general part also contains the list of used package repositories. That means that the different product medias always use the same package pool to avoid that a package can come from different projects for this product.
Furthermore it defines settings which are used in areas below, like architectures used in which combination or specific conditions for packages.
Configuration options are also grouped for the stage where they get used. This can be during media creation, during installation or in the installed system.
Media definition
A product can get shipped in multiple forms. Each form is classified as a flavor of the product. The flavors can be multiple media sets, one for each defined architecture set.
The media definition also contains the definition of the used packages for the repository on the media. These can be provided by groups. These groups can get shared between the medias or even between product definitions.
The groups or packages can get assigned to options:
- Conditions can define that a package should get taken from specific architectures based on the base architecture.
- Packages can get force to a medium, if multiple mediums are wanted for this flavor.
Last but not least, the build service can collect debug or source packages automatically and put them on a given media.
Additional files on the media can get extracted by metapackages. These packages get unpackaged and their content get stored directly on the media.
In future releases it is planned to allow also to create patterns automatically from the group files. Currently the patterns get maintained via the meta packages.
Format spec
A more or less complete example file is now available here. TODO: create a dtd !
How to deal with product definitions in the Build Service
The openSUSE Build Service can process product definition files and build the desired medias automatically.
How to store a product definition file
Product files needs to get stored in a package called "_product". You can create this in any project of the build service, since the product file itself specifies the used repositories.
The file name for the product file needs to match the defined name inside of the definition plus a .product suffix.
How does the Build Service process them
The Build Service runs the product converter on each source change in the _product package. It creates automatically the following further packages in _product:*
- release package spec files, these are rpm packages which get created for each flavor and are used to indentify the installed product in the installed system.
- A kiwi package for each flavor and each architecture set. The kiwi package gets processed by the build service as usual and create the desired images or ftp trees.
The product converter is part of the obs-productconverter package and can get installed and runs independend of any build service server instance.
How to setup a project for the image builds
TODO Note: The Build Service running at opensuse.org does not allow image builds by default.
Examples
A good idea to check for example is to check out the current product files from our Factory projects. We try to keep them all the time updated and to add comments to the files to make them better understandable.
Add-On product
A minimal Add-on Product can look like this:
<?xml version="1.0" encoding="UTF-8"?> <productdefinition xmlns:xi="http://www.w3.org/2001/XInclude"> <products> <product id="openSUSE-Addon-MickeyMouse"> <vendor>Walt Disney</vendor> <name>openSUSE-Addon-MickeyMouse</name> <version>11.2</version> <release>0</release> <description> Your openSUSE installation will hear anything and giggle in an obtrusive way. </description> <buildconfig> <producttheme>openSUSE</producttheme> <betaversion>Alpha 1a</betaversion> </buildconfig> <installconfig> <datadir>suse</datadir> <descriptiondir>suse/setup/descr</descriptiondir> <releasepackage name="openSUSE-Addon-MickeyMouse-release" flag="EQ" version="11.2"/> <distribution>openSUSE-Addon-MickeyMouse</distribution> </installconfig> <runtimeconfig/> </product> </products> <repositories> <repository path="obs://openSUSE:Factory/standard"/> </repositories> <xi:include href="archsets.inc" /> <mediasets> <media type="cd" product="openSUSE-Addon-MickeyMouse" name="openSUSE-11.2-Alpha0-Addon-MickeyMouse" flavor="cd" sourcemedia="0" use_required="true" use_recommended="true" use_suggested="false"> <use group="DVD-selection" create_pattern="false" /> <archsets> <archset ref="x86_64" /> <archset ref="i586" /> </archsets> <archsets> <archset ref="ppc" /> </archsets> <metadata> <package name="skelcd-openSUSE" /> </metadata> </media> </mediasets> <group name="DVD-selection"> <packagelist> <package name="ear-enlarger"/> </packagelist> </group> </productdefinition>
Full distribution
conditionals
To avoid replication, someone can define "conditionals" like:
<conditional name="baselibs_only_x86_64"> <platform onlyarch="x86_64" /> </conditional>
which can be re-used in each group. Think of conditionals as "macros" in other contexts.