openSUSE:Packaging for Leap

Jump to: navigation, search


This article will give you a view from the contributor perspective on openSUSE Leap. Many of the concepts, commands to execute, people to talk to and so on are very similar to openSUSE Factory. It is recommended to use the How to Contribute to openSUSE Factory guide as a starting point, with this guide focusing on the differences specific to openSUSE Leap. This article will show that contributions to Leap is both easy and very welcomed.

When can packages be submitted into Leap

In general, packages can only be added to an openSUSE Leap version during its development, not after its release. Any exceptions have to be approved and processed by the Maintenance team.

Packages that are already in openSUSE Factory will not automatically show up in Leap. Acceptance in Factory usually is a precondition though.

How do packages from SUSE Linux Enterprise get to openSUSE Leap?

openSUSE Leap 15.3+ is built on top of binary packages from SUSE Linux Enterprise 15 and community packages which are newly maintained as part of openSUSE Backports project. This required quite large effort to unify feature set within SUSE Linux Enterprise and openSUSE Leap. This is being referred to as Closing the Leap Gap (CtLG) effort.

openSUSE Backports project was previously rebuilding sources from openSUSE Leap and providing binary rpms to users of SUSE Linux Enterprise via a Package Hub module. openSUSE Leap 15.3 is bringing Staging projects to openSUSE Backports and utilizes the project for development of its community packages. The very same rpms are then shipped to users of SUSE Linux Enterprise via Package Hub module, and eliminating need to build same sources twice.

Both sources and binaries from all packages in SUSE Linux Enterprise products (including Enterprise Storage, RT etc) are mirrored after build event from OBS to IBS unless they're explicitly Blacklisted from sync.

The source of truth for the Blacklist is maintained internally by SUSE's autobuild team, the wiki page is its manually updated copy. An example of project containing binaries and sources synced from SLE-15-SP3:GA in SUSE's Internal OBS instance (IBS).


How to update a particular package in SUSE Linux Enterprise?

This would be only the case when a package update is blocked on an update of a particular library which is inherited to Leap from SUSE Linux Enterprise. Packages in SUSE Linux Enterprise need to be updated in SUSE Internal instance of OBS reffered to as IBS.

For better coordination, openSUSE Leap users and contributors can request particular package updates in SUSE Linux Enteprise at our public feature tracker . These get review every Monday at a public Feature review meeting.

Packages from SUSE Linux Enterprise can receive contributions from community via submit request mirroring. However, this is bit problematic as we do not support two way synchronization of comments in between IBS and OBS and status updates doesn't work at the moment. So best to communicate in feature tracker or over email.

How to add a new package to an openSUSE Leap release in development

Note that even though openSUSE Leap 15.3+ is being mentioned in the examples, this section applies to openSUSE Leap 15.6, currently. Previous versions are now either under maintenance, or reached end of life. See this page for more details.

Leap is a stable release built by combining binary packages from SUSE Linux Enterprise and sources from openSUSE Tumbleweed. Packages from openSUSE Tumbleweed (also refereed to as Community packages) are new maintained inside openSUSE Backports project.

For people familiar with the Factory Development Model, Factory serves a purpose for Leap similar to the purpose a devel Project serves for Factory.

By default new packages for Leap must either come from SLE or be accepted in Factory first.

New packages should be preferably introduced on the openSUSE Factory mailing list with a link to the submit request. A good introduction contains information on the state of the upstream project, how maintainable it is and what the purpose of having it in the distribution will be.

Packages can be updated by sending submit request to openSUSE:Leap:15.6, which is then automatically redirected to the proper origin (SLE or Backports). But a new package request has to be explicitly submitted against the intended destination project that will be in 99% openSUSE:Backports:SLE-15-SP6. An example of submitting from the Factory devel project to Leap 15.3+:

user $ osc submitrequest -m 'Submitting Factory version of Salt for openSUSE Leap, see https://lists.opensuse.org/opensuse-factory/2015-07/msg00443.html ' systemsmanagement:saltstack/salt openSUSE:Backports:SLE-15-SP6

It's also possible to submit from Factory, but that requires extra hacks:

user $ osc submitrequest -m 'Submitting Salt for openSUSE Leap, see https://lists.opensuse.org/opensuse-factory/2015-07/msg00443.html' openSUSE:Factory/salt openSUSE:Backports:SLE-15-SP6
New packages should be submitted directly into openSUSE:Leap:15.6 project only in following cases:
  • -branding packages, we have to rebuild these explicitly for Leap;
  • If we need to override a package inherited from SUSE Linux Enterprise;
  • Non-SLE Kernel Module packages (KMP). The current openSUSE:Backports setup doesn't allow to build KMPs, so they have to be built and maintained inside the openSUSE:Leap:15.6 project.

New packages can be submitted to SUSE Linux Enterprise projects (e.g. SUSE:SLE-15-SP6:GA) only in case of approved feature request. We expect these new SLE package requests to be more likely corner cases, while upgrade requests will be quite common. Perhaps if we agreed with community that the initial effort will be done outside of SUSE, but we have an agreed internal maintainer to take care of future updates.

Because of bugs in OBS, ~/.oscrc must have submitrequest_on_accept_action unset, and there must be no --cleanup nor --no-cleanup specified on the osc command line. Otherwise, OBS would return a permission error.

If a package for Leap for whatever reason cannot be taken from either SLE or Factory the reason for that should be explained in the submit request.

How to upgrade a package in an openSUSE Leap release in development

All upgrade / updates requests should be sent against openSUSE:Leap:X.Y (e.g. openSUSE:Leap:15.6) project. Submit request redirection will automatically send the request to the origin project of the package (openSUSE:Backports*, SUSE:SLE*, or in very few cases openSUSE:Leap:15.3+).

In case of SUSE:SLE, submit request will have to be mirrored to SUSE's Internal OBS instance (IBS).

In general, version updates of packages are possible in minor Leap version upgrades. The packager should carefully consider the pros and cons of such upgrades for the users, though. Within a major version Leap is considered stable, so overly disruptive and incompatible changes are to be avoided. After careful consideration of the pros and cons the same process as with new packages applies. I.e. packages must be accepted in Factory first.

All changes to packages from SUSE Linux Enterprise will require an issue reference. See openSUSE:Suse_sle_review_team.

How to add a new package to a released openSUSE Leap version

See Maintenance Portal and Maintenance submission.

Please be aware that packages which are inherited from SUSE Linux Enterprise will require to follow standard process for late/maintenance feature requests. You will need JIRA feature request and an additional ECO approval. This approval will be requested by TAM / Release manager for openSUSE and linked as blocking the underlying feature request.

Agreed differences from Factory

In some cases, we really want to maintain a separate code-stream of application in Leap and SUSE Linux Enterprise e.g. staying with particular version of library or application, while Factory has already way newer version. Another case could be to keep a specific patch. Such cases should be tracked in this table. Ideally this table should be filled as part of agreement to have a divergence e.g. in SLE or Leap Feature requests.

Package name Difference Reasoning
Example Example Example
Example Example Example
Example Example Example


Development Information

Project Layout

openSUSE:Backports:SLE-15-SP6: all community maintained packages with free license for openSUSE Leap and Package Hub module for SLE in this project.

openSUSE:Backports:SLE-15-SP6:Update: updates for all community maintained packages with free license for openSUSE Leap and Package Hub module for SLE in this project.

openSUSE:Leap:15.6: Leap Branding packages, kernel modules and SLE packages that were agreed to be rebuilt for Leap

openSUSE:Leap:15.6:NonFree: packages with non free licenses

openSUSE:Leap:15.6:Update: Updates to Leap Branding packages, kernel modules and SLE packages that were agreed to be rebuilt for Leap

openSUSE:Leap:15.6:NonFree:Update: updates for packages with non free licenses

openSUSE:Step:15-SP6: Armv7 enablement [1]

openSUSE Leap consumes SLE binary packages and sources from following project structure. Individual Service Packs inherit packages from older Service Packs. Unless certain package was not updated since the original release of SLE-15 you would inherit it from SLE-15:GA. If there was an update in Service Pack 3, we would inherit it from SLE-15-SP3:GA. Or even SLE-15-SP3:Update, if it was a maintenance update post SLE 15 SP3 GA and so on.

What's important is that updates to these packages must end in their respective project. To figure out origin of the package, you can use:

user $ osc meta pkg $prj $pkg

If the package comes from already unsupported Service Pack, then the update should be sent against the oldest supported one (SLE-15-SP2:Update) or to the currently developed Service Pack (SLE-15-SP4:GA) in case that the change is intrusive or doesn't generally make sense for older service packs. In such case you will want to specify the project in osc submitreq manually and not rely on SR redirection. As another way to find out where a given package is being currently maintained, you can use:

user $ osc maintained $pkg

See details about SLES 15 lifecycle.

SUSE:SLE-15:GA
Binary Packages and sources inherited from the very first release of SLE 15 SUSE:SLE-15:GA

SUSE:SLE-15:Update
SUSE:SLE-15-SP1:GA
SUSE:SLE-15-SP1:Update
SUSE:SLE-15-SP2:GA
SUSE:SLE-15-SP2:Update LTSS ends at 31 Dec 2024
SUSE:SLE-15-SP3:GA
SUSE:SLE-15-SP3:Update
SUSE:SLE-15-SP4:GA
SUSE:SLE-15-SP4:Update
SUSE:SLE-15-SP5GA
SUSE:SLE-15-SP5:Update
SUSE:SLE-15-SP
6:GA
Currently developed

Upstream Projects

Many packages in openSUSE Leap 15.5 come from other projects, namely SUSE:SLE* and openSUSE:Backports. During the development phase, release engineers may pull package updates from those. To query for the origin of a package use:

user $ osc meta pkg openSUSE:Leap:15.5 $pkg
SUSE:SLE-15-*
SUSE Linux Enterprise sources and binaries: pulled automatically via source and binary sync from SUSE Internal OBS instance (IBS).
openSUSE:Factory
Factory package updates: pulled automatically until package freeze.

RPM Distro Version Macros

  • Use suse_version 1315 to refer to the full life time of SLE12 and openSUSE:Leap:42.x;
  • Use suse_version 1500 to refer to the full life time of SLE15 and openSUSE:Leap:15.x;
  • Additionally, use is_opensuse 1 for openSUSE:Leap:* to mark agreed differences. See SLE Feature identicality page.
Important Update as of 2021: is_opensuse should ideally not be used only by itself. To distinguish between openSUSE Tumbleweed and SUSE Linux Enterprise check for the presence of sle_version. openSUSE Leap 15.3+ should have the identical functionality as of SUSE Linux Enterprise.
SLE 15 SLE15:GA SLE15:SP1 SLE15:SP2 SLE15:SP3 SLE15:SP4 SLE15:SP5 SLE15:SP6 Backports:SLE-15
suse_version 1500 1500 1500 1500 1500 1500 1500
sle_version 150000 150100 150200 150300 150400 150500 150000³
is_opensuse n/a n/a n/a n/a n/a n/a 1
is_backports n/a n/a n/a n/a n/a n/a 1⁴
Leap 15 and TW Leap 15.0 Leap 15.1 Leap 15.2 Leap 15.3 Leap 15.4 Leap 15.5 Leap 15.6 Tumbleweed
suse_version 1500 1500 1500 1500 1500 1500 1500 1699¹
sle_version 150000 150100 150200 150300 150400 150500 150600 n/a
is_opensuse 1 1 1 1 1 1 1 1
is_backports n/a n/a n/a n/a n/a n/a n/a n/a
SLE 12 SLE12:GA SLE12:SP1 SLE12:SP2 SLE12:SP3 SLE12:SP4 SLE12:SP5 Backports:SLE-12
suse_version 1315 1315 1315 1315 1315 1315 1315
sle_version 120000 120100 120200 120300 120400 120000³ 120100
is_opensuse n/a n/a n/a n/a n/a n/a 1
leap_version² n/a n/a n/a n/a n/a n/a n/a
is_backports n/a n/a n/a n/a n/a 1⁴ n/a
Leap 42 Leap 42.1 Leap 42.2 Leap 42.3
suse_version 1315 1315 1315
sle_version 120100 120200 120300
is_opensuse 1 1 1
leap_version² n/a 420200 420300
is_backports n/a n/a n/a
  1. Never rely on this version, it may change
  2. leap_version is deprecated, use is_opensuse and sle_version instead
  3. Backports:* projects inherit the %sle_version macro from the corresponding SLE release now
  4. is_backports is set on all openSUSE:Backports:SLE-*-* projects

For cross distribution have a look here: openSUSE:Build_Service_cross_distribution_howto

Tips and Tricks

Package not checked in for weeks

Build failure in Staging:adi

All package submissions are built isolated in openSUSE:Leap:15.6:Staging:adi:<number> to make sure the submission is complete. Sometimes that fails due to different configurations in the devel project for example. Sometimes other packages need to be grouped into the same project. Talk to the release team if a package needs manual help there.

Factory review

The 15.6 submissions wait for the submission to Factory in order to pass reviews there. Sometimes leaf packages have to wait a long time due to low priority. If a Factory submission is stuck e.g. in legal review for too long and it affects 15.6 talk to the release team so they can adjust priorities.


suse-sle-review

openSUSE Leap 15.3+ is based on binary rpms from SUSE Linux Enteprise 15. Contribution to these packages requires additional review from openSUSE:Suse_sle_review_team.

All submissions should reference either SUSE's Jira feature reference jsc#OPENSUSE-123 or a bug reference boo#123456 or bsc#123456.

Community feature request process for SUSE Linux Enterprise and openSUSE Leap is documented here =

Maintainer review

Packages submitted by someone other than the Factory package maintainer(s) have a review set to the devel project/package to ask for permission by the Factory package maintainer. If there's no reply for too long, try adding a comment in the request to get some attention or talk to the project maintainers directly.