Architectures

Fedora Architectures

Author: Tom 'spot' Callaway, others

Structure

There are two tiers of architectures with Fedora support:

• Primary Architectures : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).
• Alternative Architectures : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures.

Primary Architectures

• ARM-hfp (32-bit, little-endian, hfp for ARMv7→) (as of Fedora 20, until Fedora 37)
• x86 (32-bit for i686→) (until Fedora 25)
• x86_64 (v1 64-bit)
• ARM AArch64 (64-bit, little-endian for ARMv8→)

Alternative Architectures

• ARM-sfp (32-bit, little-endian, sfp for ARMv5→)
• IA64
• MIPS-64el (mips64r2, little endian, n64 ABI)
• MIPS-el (mips32r2, little endian, o32 ABI)
• MIPS-n32el (mips64r2, little endian, n32 ABI)
• Parisc
• PowerPC (32-bit)
• PowerPC64 (64-bit, big-endian for POWER5→)
• PowerPC64le (64-bit, little-endian for POWER8→)
• RISC-V (64-bit open source ISA)
• s390x (64-bit for zEC12→)
• SPARC (32-bit)
• SPARC64 (64-bit for sun4u→)
• x86 (32-bit for i686→) (Fedora 26 until Fedora 30)

Architecture Maintainer Teams

In order to manage and support alternative architectures, each alternative architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead.

Architecture Maintainer Team Responsibilities

• Receiving notifications of alternative arch build successes and failures
• Patching packages cleanly such that they build and function correctly on the alternative architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages, permitting them special access to make changes. This ability requires a great amount of respect, and alternative architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.
• Resolving architecture specific bugs filed against packages
• Holding regular status meetings on IRC for the architecture
• Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for alternative architectures can be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If an alternative architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.
• Maintaining and hosting the buildserver(s) and storage for that architecture
• working with Release Engineering on Composing trees for that architecture
• Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.
• Participate in and give progress reports to the Release Engineering meeting on a weekly basis

Each alternative architecture maintainer team will have a dedicated mailing list (e.g. [email protected]) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.

There is a generic alternative arch list at [email protected] one or more team members should subscribe here.

In addition, alternative architecture teams should do the following:

• Run regular 'rebuild all in mock' runs (usually requires dedicated system)

Logistics

Buildsystems

Alternative architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to guarantee to provide hosting space for Alternative Architecture systems at this time. Alternative Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors. All builds have to happen in a native environment. this means cross compiling is not allowed, you can however use virtualisation to emulate your target system.

File Storage

Alternative architectures will need to provide their own file storage for the buildsystem, there may be some available from Fedora Infrastructure, composed trees will be hosted at https://dl.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror alternative architecture trees on an arch-by-arch basis.

Tree Composition

Fedora Release Engineering will not have any responsibility for composing Alternative Architecture trees for Architectures that are built outside of primary koji. Composing trees and install media is the responsibility of the Alternative Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).

Sandbox Systems

Alternative architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.

***TODO*** Document how to set this up.

While sandbox systems are very useful for Fedora packagers who would not normally have access to the hardware architecture, they are not a requirement.

Packaging Issues

Divergence from Primary Architectures

Alternative architecture package trees should be as close to primary architecture package trees as possible. Alternative architectures should not use older versions and must not use customized (hacked up) packages. Alternative architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support alternative architectures must be committed in GIT for each package.

ExcludeArch & ExclusiveArch

Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.

By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new alternative architectures, rather than being immediately ignored by a blanket ExclusiveArch. There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling

Tracker Bugs

Any packager which excludes an architecture for a package needs to open a bug report against an ExcludeArch blocker bug. This will help the architecture team track and fix packages for their architecture.