Home Wiki > openSUSE:Package maintenance
Sign up | Login

openSUSE:Package maintenance

tagline: From openSUSE

This document describes how packagers can submit updates for released openSUSE products as part of the maintenance process.
Warning All packages in the openSUSE build service are fully public. Therefore the build service cannot be used to prepare embargoed security updates. In case of an embargoed update the packager has to wait until end of the embargo before checking in the fixes
Warning Before you start working on a Leap package, please check the maintenance process.

Find the package that you need to work with

The build service contains many different versions of packages. Some may be official releases and others may be under development by users in their home projects. The easiest way to find which versions are candidates for maintenance, use the osc maintained command. We'll use the nfs-utils package as an example.

$ osc maintained nfs-utils

openSUSE:Leap:42.2:Update/nfs-utils
openSUSE:Leap:42.3:Update/nfs-utils

Create a branch

The build service provides an easy way to work on packages without having to unnecessarily contaminate the original package. It allows the user to check out a private version of the package into their home project. Any changes committed to it will be stored as a set of changes to the original. This has the advantage of making the differences between the two projects obvious when the branch is eventually submitted back to the original project.

The process for creating a branch of a single package from a single project is:

$ osc branch -M -c openSUSE:Leap:42.3 nfs-utils
[...]

In this case an update for nfs-utils was released previously already. The updated sources got stored in a different project, openSUSE:Leap:42.3:Update. You don't have to bother about that detail. osc automatically does the right thing and uses the updated sources. So just follow the instructions provided and check out your branched copy of the package:

If you already have a branch for this package, you should remove and recreate it. A branch that is still around and you wonder why needs investigation. It may mean that a submit-request was not accepted, and thus the cleanup never triggered. Removing such a branch may destroy your previous work.

The branch point exists from the point in time that you created it. If other changes have been committed in the interim, they will be lost if you use your existing branch. You can delete the branch by deleting the package with the osc rdelete project package command. For the our example, it would be osc rdelete home:BenniBrunner:branches:openSUSE:Leap:42.3:Update nfs-utils.openSUSE_Leap_42.3_Update.

Branching all code streams at once

Sometimes you need to update a package for all maintained code streams, e.g. for a security fix. With the method described above you'd have to branch and check out the package two times, once for Leap 42.2 and Leap 42.3.


The osc mbranch command will make that convenient. It can query the build service to find the list of projects where a package is flagged for maintenance.

Warning This relies on correct configuration within the build service. Please consult with the maintenance team, if you suspect the list of projects used by osc mbranch is incorrect.

osc mbranch collects all copies of the package from all projects flagged for maintenance and creates branches of those packages in one project:

$ osc mbranch nfs-utils
Project home:BenniBrunner:branches:OBS_Maintained:nfs-utils created.

$ osc co home:BenniBrunner:branches:OBS_Maintained:nfs-utils
A    home:BenniBrunner:branches:OBS_Maintained:nfs-utils
A    home:BenniBrunner:branches:OBS_Maintained:nfs-utils/nfs-utils.openSUSE_Leap_42.2_Update
[...]
A    home:BenniBrunner:branches:OBS_Maintained:nfs-utils/nfs-utils.openSUSE_Leap_42.3_Update
[...]

Warning If you have multiple spec files in your package, please use osc ls home:username:branches:OBS_Maintained:packagename to double-check that packages were created for all spec-files.

Getting the list of maintained copies manually

If still in doubt, please contact the maintenance team for the correct list.

Make your changes

Now that you have a private copy of the package, you can make whatever changes you need to the package. The easiest way to handle updating the file list is to ensure that you don't have any temporary files still in the source package directory and use the osc addremove command.

If you add new patches, make sure to follow the Patch tagging guidelines.

Once you've completed your changes, add an entry to the .changes files using osc vc.

  • briefly describe the problem, one line per problem
  • include a reference to the bug number in the form (bnc#12345) (mandatory for maintenance updates)
  • for security fixes include the CVE number if available.

Finally commit your changes to your branch with the osc commit command.

See HOWTO write good changes

Submit your changes

Your branch is now a separate package and will build independently in your home project. It's generally a good idea to ensure that it builds within the tight constraints of the build system and is tested properly before submitting it. The submit process is simple.

From your checked-out project directory:

$ osc mr 
created request id 22864

All packages from a remote-project:

$ osc mr $prj
created request id 22864

A specific package from a remote-project:

$ osc mr $prj $pkg $target #(e.g. $target could be openSUSE:Leap:42.3:Update)
created request id 22864

A sub-set of packages from a remote-project:

 $osc mr $prj $list $of $packages $target
 created request id 22864

Osc will prompt you for a message for the submit request. Usually you just use the same message as for the .changes file.

If the above doesn't work, you can try, from the checked-out package directory:

$ osc sr
WARNING:
WARNING: Project does not accept submit request, request to open a NEW maintenance incident instead
WARNING:
created request id Request: #180441