This wiki was updated to MediaWiki 1.37. If you notice any issues, please report them to admin[at]

openSUSE:OpenSUSE Distribution Architectures Policy

Jump to: navigation, search

Please discuss changes on this page prior to editing on the appropriate distribution mailing list, or opensuse-project if none exists.

Version: 20201124

What is an openSUSE distribution main architecture?


Before this policy, the openSUSE Tumbleweed distribution main architectures, which are the architectures that development, test and release are targeting, were i586 and x86_64. For openSUSE Leap distribution the main architecture has been x86_64.

This document describes the responsibilities that come with an openSUSE distribution architecture being declared a main architecture. The main architectures for an openSUSE distribution are the ones that are developed, tested and released together and carry the main distribution name.

While ports to other architectures are encouraged and their needs are handled best-effort, these ports need to document clearly that it is an architecture port of the respective openSUSE distribution.

Any architecture port of openSUSE that wants to be a main architecture has to adhere to the following guidelines. This policy is defining the minimum set of rules for that. There could be also distribution specific additional policies defined.

Any nomination for a main architecture should be brought up for discussion on the respective openSUSE distribution mailing list and also announced on the opensuse-project@ mailing list.


  • openQA: Refers to the official openSUSE openQA instance, e.g.
  • openSUSE Distribution: The binary software collections that openSUSE releases under a distribution name (e.g. Tumbleweed, Leap)

openSUSE Distribution Main Architecture Policy

openSUSE includes and welcomes additional architecture ports, and favors balancing the needs of any additional architectures equally. On top of the set of additional architectures, each openSUSE Distribution can define a set of main architectures.

In order for an architecture to be a main architecture, the following requirements shall be met:

  • There is an active set of regular contributors that care about the distribution build and is reachable via a common mailing list for questions from packagers in case of architecture specific defects ('Architecture Team'). This Architecture Team contributes to and co-maintains the openQA test automation for this architecture. At least one member participates in the weekly openSUSE release team meeting.
  • The distribution milestones releases should always pass a common subset of openQA tests that make sense for this architecture. Although temporary regressions are acceptable, the distribution team should strive for the tests coverage to be continuously improved both in coverage as well as in number of passing tests.
  • A full Bootstrap of the distribution can be built entirely from reviewed sources starting from a set of trusted binaries. No source change is published to users on that distribution that hasn't been peer reviewed by the openSUSE Review Team.
  • The distribution maintainers are filing bugreports on for package maintainers if there are issues identified in the architecture port. The package maintainers commit to handle primary architectures with care and test-build them in the development projects before submitting changes. The package maintainers commit to handle regressions quickly and in general accept bugreports for that platform and work on a resolution.
  • The architecture team is at all times focused on keeping every package re-buildable from sources. There should be always less than 5% of the packages failing to build from source at any point in time, and core packages for the distribution (e.g. defined as Ring-0 today) should always be successfully re-buildable and passing their build-defined test suite. A new build failure of a submission on the primary architectures is a valid reason for declining the submission.
  • The distribution build is providing tested, working set of build artifacts (Packages, Container, Installation Images, Machine images) for that architecture.
  • All main architectures respect and follow the distribution release schedule. This means that artifacts for all main architectures are available on the same release day. In the case of a rolling release, all artifacts for main architectures are made available without a larger delay from each other.

openSUSE Tumbleweed Main Architecture Policy

  • The Tumbleweed version of the distribution is regularly publishing new snapshots (at least once a month). The openSUSE releases are published if and only if passing the defined openQA tests, which gives users the stability requirements they expect from a primary architecture.
  • The Tumbleweed version of the distribution is taking appropriate measures to keep Ring 0 and Ring 1 packages buildable from source at any point in time. This can be for example by ensuring that no package source enters that would fail significant parts of the Rings, or can be by backing out problematic changes until the underlying issue has been fixed.
  • The Tumbleweed Distribution is built from the openSUSE Factory set of curated sources, that are reviewed by the openSUSE review team. No permanent overlays or deviations are permitted. Temporary overlays are permitted during development in case of a severe regression on that platform (example: Newest Factory kernel-source does not boot on that architecture. In that case a temporary revert to an older, previously released source is acceptable while the regression is being resolved at highest priority.). The intention here is to decouple individual architecture release processes, however not to allow for any long-standing deviations. Primary architectures should be consistent in experience and software versions that they ship at any point in time.

Q & A

Q: Which of the current Tumbleweed ports would meet criteria for being promoted main architecture?

A: as of 2020/06, our tests x86_64 (142 tests passing) AArch64 (81 tests passing), PowerPC (32 tests passing) and s390x (0 tests passing). That makes AArch64 the most appropriate candidate so far in this aspect.

Note: reference rather than just the bugzilla url, wiki page has lot more information. can be used as shorthand.

Q: Does a main architecture have to care about all the packages or are packages outside a 'core' set best effort ?

There is no hard guidelines on this established in the community as of today. However common practices focus more on the "core" package set (on x86_64 this is defined by the DVD media set) than on leaf packages. Main Architectures are defining this 'core' package set.

Any main architecture has to strive for a growing set of passing openQA tests that the distribution considers relevant to pass continuously.