openSUSE:Backports Package Submission Process

Jump to: navigation, search

Overview

This page outlines the technical process of building and maintaining packages for the SUSE Package Hub. Backported packages are built in the openSUSE build service under the openSUSE:Backports namespace.

Project Setup for Package Hub 12

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:

Packager workflow for Package Hub 12

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 an 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.

Project Setup for Package Hub 15

Package Hub 15 is a rebuild of all openSUSE Leap 15 packages that are not also in SLE or are otherwise excluded from being added to Package Hub 15. As a consequence, Package Hub 15 automatically receives maintenance update changes from Leap 15.0 that the openSUSE community delivers for these packages, with the help of SUSE employees.

The following projects exist:

Packager workflow for Package Hub 15

By default, all changes delivered to Leap 15 will be reflected in Package Hub 15 for applicable packages. Any other changes and new packages may be submitted in parallel to the following projects:

  • openSUSE:Backports:SLE-15:Update
  • openSUSE:Backports:SLE-15-SP1:Update

As a consequence, new packages and changes have the following requirements:

  • A bug entry in bugzilla, referenced in the submission
  • New packages accepted in openSUSE:Factory
  • Bug fixes first submitted to openSUSE:Factory
  • Compatible with the base Leap and it's maintenance policy.

Maintenance Workflow

The target projects do not 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 Package Hub 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.