openSUSE:Backports Package Submission Process

Jump to: navigation, search

Overview

This page outlines the technical process of building and maintaining packages for the SLE Backports repos.

Project Setup

Backported packages are built in the openSUSE build service

The following default target exists:

openSUSE:Backports:SLE-12 (SUSE Linux Enterprise Server 12 "GA" release)

The default target should be used for building and submitting all new packages. If a package requires a later service pack to build, use the appropriate target below:

The packages in older releases should, in most cases, be forward compatible with the following service pack releases. Therefore it's not necessary to rebuild for each service pack. Packages in the openSUSE:Backports:SLE-12 target will not be automatically migrated and built in the service pack targets, though they will be available at build time where needed.

Packager workflow

The Backports project only allows packages that are already accepted in Factory. Ensure that you package is accepted and building there.

You can build and locally test any checked out package:

 osc build --alternative-project openSUSE:Backports:SLE-12 standard

If the package builds, it will build in backports as well. Proceed with submitting it as a single package below.

Adding openSUSE:Backports:SLE-12 as a build target to your project is possible, and will work for developing your new packages in a separate project. It is not suitable for the general case as packages will be set to automatically fail should they duplicate packages already in the SLES product.

Introducing a single new package

A single package can be submitted as follows:

 osc sr devel:project hello openSUSE:Backports:SLE-12

Note that the package may build in devel:project but not in openSUSE:Backports:SLE-12, it is hence recommended to check for that using --alternative-project as described above or a suitable project configuration.

The build service will internally convert the submit type request into a maintenance_incident, and the following message is expected: Project does not accept submit request, a NEW maintenance incident request will be created instead

Introducing more than one package

Consider a new package (e.g. devel:project/newpackage) that also requires a new library devel:project/newlib, none of which are already in backports.

We will create a maintenance branch (-M) for a new package (-N):

 osc branch -M -N openSUSE:Backports:SLE-12/newlib
 osc branch -M -N openSUSE:Backports:SLE-12/newpackage
 osc co home:SLE_WIZARD:branches:openSUSE:Backports:SLE-12

Now we can put in our sources. In this case, we copy the sources from the devel project. We need to extend the source link (-e) as well as keep the target link in case it exists (-K).

 osc copypac -e -K devel:project/newlib home:SLE_WIZARD:branches:openSUSE:Backports:SLE-12/newlib.openSUSE_Backports_SLE-12
 osc copypac -e -K devel:project/newpackage home:SLE_WIZARD:branches:openSUSE:Backports:SLE-12/newpackage.openSUSE_Backports_SLE-12

When this is built and tested, we can submit a maintenance request for all packages together:

 cd home:SLE_WIZARD:branches:openSUSE:Backports:SLE-12
 osc mr

A combination of new and updated packages is possible.

Branching existing package

Just like with openSUSE maintenance a package can be branched directly from the destination project

 osc branch openSUSE:Backports:SLE-12 hello

Alternatively, to automatically branch all maintained versions

 osc mbranch hello

This command would set up a project that also contains all openSUSE versions of the same package so the maintainer can fix all instances at once.

Note that the current policy requires that package sources for the Backports project and openSUSE Factory are identical.

Maintenance Workflow

The target project doesn't actually build the packages but behaves like an update project for released openSUSE distributions. I.e. the actual sources are built in so called "incident projects". The openSUSE maintenance team takes care of those incident projects.

After the packager filed a request, they reviewed by automated review bots:

  • maintbot: checks if the submission was created by the package maintainer as defined in the devel project. maintbot will add the devel project as reviewer for submissions by non-maintainers.
  • factory-source: checks if the sources for submissions to the Backports project are actually accepted in factory. Rejects requests where this is not the case.
  • legal-auto: license checks

The following further reviews are added as needed:

  • for Backports team: If the sources do not match those of openSUSE:Factory or a currently maintained stable Leap distribution, this deviation must be separately approved
  • for the Factory package maintainers. If the submission is by a person who is not in the list of regular maintainers of this package in Factory, they need to separately approve it. Note that if the maintainer accepts this reviews, this also indicates that they commit to maintain the package in PackageHub for future security or maintenance issues. The following message is used: Submission for PACKAGE by someone who is not maintainer in the devel project (PROJECT). Please review.

After successful automated and manual reviews the maintenance engineer takes over. If the request is ok he accepts it and therefore creates a maintenance incident. After the packages built successfully the maintenance engineer creates a release request. The release request in turn is checked again by factory-source.

After the usual grace period for testing as used on openSUSE the maintenance engineer then accepts release requests to actually release the package.