Build Service/Concepts/Maintenance

From openSUSE

Revision as of 19:48, 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 ?

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 libqt4

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). The api call to do this is:

-X POST https://api.opensuse.org/source?cmd=branch&package=glibc&attribute="OBS:Maintained"

The api call can be extended with a "target_project=..." parameter, if you want to prepare multiple package sources in one project for one submission. For example binutils and gcc, because a problem needs fixes in both package sources.

Of course there will be an easier osc command for 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 packages, lets say glibc.

osc mbranch --checkout glibc
... fix your packages, 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 an variation of a openSUSE based product, you may want to have an own update channel. This may make sense in case you want to control the official updates for your product yourself (eG for a $BIG_COMPANY desktop).

What you need to do is to request your own attribute (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.

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 in the will be simple afterwards. You can either call

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

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

osc mbranch glibc

call as the usual openSUSE maintainers.