Architectures

Fedora Architectures

Author: Tom 'spot' Callaway
Revision: 0.06
Initial Draft: Tuesday May 15, 2007
Last Revised: Monday Aug 6, 2007

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. To put it simply: These are the architectures for which Fedora will delay a release if they are not functional. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).
• Secondary Architectures : These are architectures with motivated Architecture Maintainer Teams, and build hardware. Build failures on secondary architectures are not fatal: if packages successfully build for the primary architectures, they push independently of any secondary architecture build successes or failures.

Primary Architectures

• x86 (32-bit)
• x86_64 (64-bit)

Secondary Architectures

• ARM
• IA64
• MIPS
• Parisc
• PowerPC
• s390x
• SPARC

Architecture Maintainer Teams

In order to manage and support secondary architectures, each secondary 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 secondary arch build successes and failures
• Patching packages cleanly such that they build and function correctly on the secondary 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 (with some exceptions, such as, glibc, kernel, anaconda), permitting them special access to make changes. This ability requires a great amount of respect, and secondary 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 secondary architectures will 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 a secondary 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
• 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.
• Deliver progress reports to FESCo on a monthly basis

Each secondary architecture maintainer team will have a dedicated mailing list (e.g. fedora-sparc-list) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.

There is a generic secondary arch list at secondary@lists.fedoraproject.org one or more team members should subscribe here.

In addition, secondary architecture teams should do the following:

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

Logistics

Buildsystems

Secondary 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 provide hosting space for Secondary architecture systems at this time. Secondary 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

Secondary architectures will need to provide their own file storage for the buildsystem, composed trees will be hosted at http://secondary.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror secondary architecture trees on an arch-by-arch basis.

Tree Composition

Fedora Release Engineering will not have any responsibility for composing Secondary Architecture trees. Composing trees and install media is the responsibility of the Secondary Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).

Sandbox Systems

Secondary 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

Secondary architecture package trees should be as close to primary architecture package trees as possible. Secondary architectures should not use older versions or customized (hacked up) packages. Secondary architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support secondary architectures must be committed in CVS 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 secondary architectures, rather than being immediately ignored by a blanket ExclusiveArch.

Tracker Bugs

Any packager which sets ExcludeArch for an architecture must open a bug against that package, and block that bug against the appropriate ExcludeArch blocker bug.

This will help the Secondary Architecture team track and fix packages for their architecture.