Build Service/Concepts/Maintenance

From openSUSE

Revision as of 21:41, 1 November 2009

This Concept is in Draft state and describes the mechanisms and osc usage for creating and submitting maintainance packages. Some of this is already implemented.

Maintainance packages are official package updates for a product, like openSUSE 11.2. Beside the usual packages in a repository, there is additional information needed. These additional information describes the set of packages and the problem it tries to solve.

This concept relies heavily on the lately implemented attribute system.

What are maintained packages ?

Maintained packages are all packages, which got released with an official product, which is not yet end-of-life. These are currently all packages which are part of openSUSE 11.0, 11.1 and 11.2.

Maintenance means that critical updates, like security updates for these packages shall be released on need. Usually the fixes get backported to the package version of the product. This is done to avoid behaviour changes as much as possible, which may happen on version updates.

Mark packages as maintained

The OBS shall know the currently official maintained packages. This happens by creating the "OBS:Maintained" attribute. We set this currently only in the projects openSUSE:11.0, openSUSE:11.1 and openSUSE:11.2 and their :NonFree pendants. This means all packages inside of them are maintained. But we could also set single ones in any other package sources.

Find maintained packages

The frontend search by attribute function allows use to search for maintained packages fast. The XPath "attribute/@name='OBS:Maintained'" search term may be used together with a package source name to find all package instances in all projects.

The osc command

# osc maintained <PACKAGE>

is aimed to do this. An alternative search method is

# osc search --package <PACKAGE> --exact --limit-to-attribute='OBS:Maintained' --bugowner

Create your branch project to prepare your submission

The api allows to create one branch project, which hosts all instances of one or multiple packages for one or multiple projects (aka distributions). You can reuse the new created project for another package if you want to prepare multiple package sources in one project for one submission. For example when binutils and gcc needs both fixes in their sources to solve one problem.

The osc command for this may look like this:

osc mbranch glibc

As described before the result is a single project, by default "home:<user>:branches:OBS_Maintained:<package>". This project will contain the source packages

glibc.openSUSE_11.0
glibc.openSUSE_11.1
glibc.openSUSE_11.2

The project may have also repositores name like these

openSUSE_11.0_Update_standard
openSUSE_11.1_Update_standard
openSUSE_11.2_standard

This means that it found existing updates of glibc in the update repositories for 11.0 and 11.1. The build will be only enabled for the right repos per package source. The update projects are defined in the "OBS:UpdateProject" attribute inside of the main distro projects (openSUSE:11.x).

Submit your maintainence update

Write your patchinfo informations

The OBS can't take 100% over the writing of patchinfo informations, but it can help. After having all packages successfully building, please call

osc patchinfo -e

It requests a patchinfo file template from the server. The server extends informations inside of it already with all informations it has. After editing it, it will be stored in _patchinfo package and can get submitted.

Submit your changes

A usual osc submitrequest call is used for submitting your changes. It is currently undecided if osc will create multiple or one submitrequest call.

Sample workflow

Simple Case

A update for a single package, lets say glibc.

osc mbranch --checkout glibc            # is doing branch and checkout in one step
... fix your packages, let build them all and hopefully you test them also :)
osc patchinfo -e
osc sr

done. So these are three simple steps and afterwards you have submitted your packages for all distros.

Multiple packages submission

An example for multiple package source submission is the kernel. We can handle this via one mbranch call:

osc mbranch --checkout kernel-source kernel-default ...

After fixing the sources, we want to create a patchinfo file called "kernel":

osc patchinfo --name "kernel" -e

Note: A feature which handles the packages, which belongs together (connected via source link) automatically will be implemented in future.

Multiple packages step by step

We may discover during fixing that we need to update also another package for this submission.

osc mbranch mozilla
osc co home:adrian:branches:OBS_Maintained:mozilla
...
osc mbranch --target-project home:adrian:branches:OBS_Maintained:mozilla xul-runner
osc up
...

If xul-runner update is needed for openSUSE 11.0, but not for 11.2 for example, we can remove the sources of xul-runner for 11.2. So the "osc patchinfo" command will automatically create a template which skips it already.

Further possibilities

Mark packages for a concrete update

Individual teams may collect informations for a update. This may look like this: The security team marks the packages openssl in openSUSE:11.0 and openSUSE:11.1 and the gnutls in openSUSE:11.2 with the same marker. For example in the "SecurityTeam:Maintenance" attribute with the value "CVE-13".

The responsible person, to fix this can just call

osc mbranch -a "SecurityTeam:Maintenance/CVE-13"

to get a branch with all the needed sources.

Work with an own Update Project

As an owner of a variation of a openSUSE based product, you may want to have an own update channel. This make sense in case you want to control the official updates for your product yourself (eG for a $BIG_COMPANY desktop). These updates may be for packages of the openSUSE distro you use or for the additional packages of your own project.

What you need to do is to request your own attribute type (or even your attribute namespace). Afterwards, you can store an attribute in all projects you want to maintain and their update projects. Let's say you use the attribute "TimUndStruppi:Maintained" and you have marked the project home:TimUndStruppi and some packages in the openSUSE:11.2 project you use.

Your official update project may be home:TimUndStruppi:Update . So you should set also the "TimUndStruppi:UpdateProject" attribute, with the value "home:TimUndStruppi:Update" in the projects home:TimUndStruppi and openSUSE:11.2.

Yes, this sounds complex, but it is also powerfull, since the daily usage will be simple afterwards. You can either call

osc mbranch -a TimUndStruppi:Maintained -u TimUndStruppi:UpdateProject <package>

or defining these both values in your .oscrc, so you can use the same simple

osc mbranch glibc

call as the usual openSUSE maintainers.

Implementation Details

Branch By Attributes API Call

The api frontend offers a variation of the existing branch call, allows to create a single project with all package instances having a certain attribute.

An example api call for creating a branch of all maintained glibc packages is

POST /source?cmd=branch&package="glibc"&attribute="OBS:maintained"&target_project="optional_project"&update_project_attribute="OBS:UpdateProject"&attribute_value=""

This creates a project (home:<username>:branches:OBS_maintained:glibc by default), which links all package instances inside, for example as glibc.openSUSE_11.1 and glibc.openSUSE.11.2. It also creates all repositories to build against, but only enables the matching repos.

Patchinfo API Call

The patchinfo call sends back a template for a patchinfo file. It checks all built binary packages and may use attribute values to fill values like bugnumbers:

POST /source/<PROJECT>?cmd=patchinfo&name="<PATCH_NAME>"

Patchinfo storage

Patchinfo files get stored in package container "_patchinfo" with its patch name. The informations gets stored in following xml:

<patchinfo name="kernel">
  <binarypackage>glibc</binarypackage>
  <binarypackage>glibc-devel</binarypackage>
  <category>security|normal|optional|feature</category>
  <summary>short description</summary>
  <description>long description of the problem and solution</description>
  <bugzilla>0815<bugzilla>
  <bugzilla name="bugs.kde.org">379<bugzilla>
  <swampid>13</swampid>
  <rating>critical/important/moderate/low</rating>
  <packager>adrianSuSE</packager>
  <zypp_restart_needed />
  <reboot_needed />
  <relogin_suggested />
  ...
</patchinfo>

Update Repository Creation

The OBS publisher shall be extended to create the patch repo based on the built packages and patchinfo files.

FIXME: how to handle the binary copies, not to loose former packages and how to create patch.rpms.