openSUSE:Backports Package Submission Process
This page outlines the technical process of building and maintaining packages for the SUSE PackageHub. Backported packages are built in the openSUSE build service.
Project Setup for PackageHub 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:
- openSUSE:Backports:SLE-12-SP1 (SUSE Linux Enterprise Server 12 Service Pack 1)
- openSUSE:Backports:SLE-12-SP2 (SUSE Linux Enterprise Server 12 Service Pack 2)
- openSUSE:Backports:SLE-12-SP3 (SUSE Linux Enterprise Server 12 Service Pack 3)
Packager workflow for PackageHub 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.
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 (
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 (
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 PackageHub 15
PackageHub 15 is a rebuild of all openSUSE Leap 15.0 packages that are not also in SLE or are otherwise excluded from being added to PackageHub 15. As a consequence, PackageHub 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:
- openSUSE:Backports:SLE-15 (PackageHub 15 original release)
- openSUSE:Backports:SLE-15:Update (PackageHub 15 maintenance)
Packager workflow for PackageHub 15
By default, all changes delivered to Leap 15.0 will be reflected in PackageHub 15 for applicable packages. Any other changes and new packages may be submitted in parallel to the following projects:
As a consequence, new packages and changes have the following requirements:
- A bug entry in bugzilla, referenced in the submission
- New packages accepted in
- Bug fixes first submitted to
- Compatible with the base Leap and it's maintenance policy.
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:Factoryor 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.