This page explains the various Fedora repositories that exist for different Fedora Releases, the relationship between them, and what packages they contain.

The fedora repository

fedora リポジトリは、 Rawhide から ブランチ した後のすべてのFedoraリリースに存在します。 It is represented for DNF in the fedora.repo file in the repository path. すべての Fedora インストールでは、このリポジトリは標準で有効になっており、通常は有効のままにしておくべきです。

The fedora repository in stable releases

安定版リリースのため、fedora ではリリース状態は凍結しています。これは、リリースが Go/No-Go Meeting で承認されたときに Release Engineering によって作成される凍結ツリーの一部です。 含まれているパッケージセットは、それ以降変更されることは決してありません。 これは、 updates リポジトリと共同して安定リリースの stable 状態を表します。

The stable release fedora repositories for the various primary architectures can be found in the /fedora/linux/releases/XX/Everything directory on the mirrors (where XX is the release), and can also be queried from MirrorManager. For instance, will return mirrors for the x86_64 fedora repository for release 37.

The fedora repository in Branched releases

In Branched releases - the state a release is in between branching from Rawhide and stable release, see Branched for more details - the fedora repository alone represents the release’s stable state. The updates repository for Branched releases is not used until they become stable. Before the Bodhi enabling point, package builds for the Branched release are sent directly to this repository. After the Bodhi enabling point, package builds that pass the Updates Policy move from updates-testing repository to this repository.

The Branched fedora repositories for the various primary architectures can be found in the /fedora/linux/development/XX directory on the mirrors (where XX is the release), and can also be queried from MirrorManager. For instance, will return mirrors for the x86_64 fedora repository for release 38.

The updates repository

updates リポジトリとは、Branched リリースおよび安定リリースのためのものですが、もっぱら安定リリースのために使用されてるリポジトリです。 It is represented for DNF in the fedora-updates.repo file in the repository path. It exists in Branched releases solely to prevent various tools that expect its existence from breaking. どの Fedora をインストールしても、このリポジトリは標準では有効であり、また、そのままにしておくべきです。

安定リリースにおいて、updates リポジトリと fedora リポジトリは一緒に、現行リリースの stable 状態を意味します。 Updates Policy に合格したパッケージビルドは、 updates-testing リポジトリからこのリポジトリに移動します。 Branched とこれの違いは、安定リリースの初期である 'frozen' 状態を正確に維持した表現をする必要があるためです。

The stable release updates repositories for the various primary architectures can be found in the /fedora/linux/updates/XX directory on the mirrors (where XX is the release), and can also be queried from MirrorManager. For instance, will return mirrors for the x86_64 updates repository for release 37.

The updates-testing repository

updates-testing リポジトリとは、 Bodhi enabling point 後のブランチリリースのため、または安定リリースのために存在しています。 It is represented for DNF in the fedora-updates-testing.repo file in the repository path. For both, it is a 'staging' location where new package builds are tested before being marked as 'stable' (and hence moving to the fedora repository or the updates repository, respectively).

これらのビルド物は アップデート候補 であるので、 the Bodhi アップデート フィードバック ツール によるレビューをされるためにあります。 according to the update feedback guidelines.

The Updates Policy defines the rules for marking update candidates as stable. The QA updates-testing page provides some information for testers on using this repository. The Package Update Guide provides information for packagers on submitting builds to updates-testing and to stable.

updates-testing リポジトリは Branched リリースでは標準で有効化されています。しかし、安定リリースでは標準では無効化されています。切り替えは、リリースごとに Final Freeze の前後に行われます。 Branched から安定版に移行するテスターが遭遇しやすいエラーとしては、現在無効になっている updates-testing リポジトリから既にインストール済みのパッケージとの間の依存関係のミスマッチという原因によるエラーがあり、この時期に更新を実行するとエラーが発生する可能性があります。 dnf distro-sync を実行したり、さらには updates-testing リポジトリを再度有効にすると、通常、問題が軽減されます。 安定版リリース後も updates-testing リポジトリを引き続き使用するかしないかは、個々のユーザー次第です。

The updates-testing repositories for both Branched and stable releases can be found in the /fedora/linux/updates/testing/XX directory on the mirrors (where XX is the release), and can also be queried from MirrorManager. For instance, will return mirrors for the x86_64 updates-testing repository for release 37.

The rawhide repository

Rawhide - これは Fedora のローリングリリースのリポジトリであり、まだ安定してないリポジトリを枝分かれ(Branched)させた物です。そういったリポジトリは rawhide だけしかありません。そのようなパッケージが Rawhide に送られます。 ファイル fedora-rawhide.repo にあるリポジトリパス(repository path) に従い、 DNF がソフトウェアを取りに行きます。 Rawhide を有効化しているシステムでのみ、ローリングリリースが有効です。Rawhide を有効化してない他のシステムでは一切、ローリングリリースを使えません。

多くの主要な アーキテクチャ 用の rawhide リポジトリは、ミラーで直接的に見つかるか、あるいはクエリを MirrorManager とやりとりしても見つけられます。たとえば でミラーは x86_64 のための Rawhide 用の fedora リポジトリを返します。

stable is not a repository

'stable repository'(安定リポジトリ)といった名称をときどき見かけるかもしれませんが、しかし Fedora においては、それは誤った名称の何かです。 stable is more of a state that can be considered to exist for both Branched releases post Bodhi enabling and for stable releases. It consists of package builds that were part of Rawhide at the time they Branched, package builds sent directly to the Branched fedora repository between the branch point and the Bodhi enabling point, and package builds that passed the Updates Policy and moved from updates-testing after the Bodhi enabling point.

ブランチリリースにおいて、 stable 状態とは、もっぱら fedora リポジトリの現行のコンテンツによる状態のことです (and, arguably, the bleed repository, but that is a small case).

For stable releases, the stable state is represented by the contents of the fedora repository combined with the contents of the updates repository.

stable is also a state a package can be considered to be in (or an attribute it can be considered to have) when it has been pushed stable or tagged stable and exists in, or will soon exist in, a stable repository for a release - whichever literal repository that is (see above).

Installation and Product repositories / trees

The repositories referred to above are neither associated with a specific Product, nor part of an installable tree (a tree containing the necessary files to be used as a base repository by Anaconda, the Fedora installer). Specialized repositories exist for these purposes.

For releases - and later - there is (as of September 2014) no installable tree not associated with a specific Product. The installable trees for various Products can be found under /fedora/linux/releases/XX/ on the mirrors for stable releases, and under /fedora/linux/releases/test/ for Branched pre-release milestones. They can also be queried from MirrorManager. For instance, will return mirrors for the x86_64 current installation repository for Server.

These repositories are frozen (new packages are not pushed to them) and are created at various points in the Fedora Release Life Cycle. A new installation tree (containing a repository) is built for several Products for each test compose or release candidate build, and the trees for the Alpha and Beta releases are made available on the mirrors in the directory (see above). They contain a subset of the full package set that is considered to define each Product.

The Product trees for the GA (Final) release are made available in the /releases tree on the mirrors.

At any given point in the release cycle, the MirrorManager request for a Product repository may redirect to a test compose / release candidate tree, a pre-release milestone tree, or the Final release tree.

These repositories are usually not used or enabled by default on installed systems, as for that purpose they are redundant with one of the three primary repositories described above. However, one could use a Product repository in place of the fedora repository to keep a system limited to the Product package set. They are represented for DNF in the fedora-(product).repo file in the repository path, which may well not be installed on many systems.

Other repositories

There are other repositories that fulfil various niche purposes, which are documented here for the sake of providing a comprehensive reference. They should not usually be significant to the vast majority of Fedora users. None of these repositories is represented in a packaged repository file, enabled by default, or should usually be used in a Fedora installation.

The bleed repository

The bleed repository exists for a single purpose: during Milestone freezes, it contains packages that have been granted 'freeze exceptions' via the Blocker Bug Process or Freeze Exception bug process, and which are desired to be included in the next test compose or release candidate build, but have not yet reached stable state and hence been moved to the fedora repository. In other words, it contains packages explicitly required in TC/RC compose requests.

The bleed repository can be found here, but again, is not usually of interest to the vast majority of Fedora users. The packages it contains are always also available from the build system, Koji, and usually from the updates-testing repository.

The latest repositories

The latest repositories contain packages for various build 'tags' as they arrive in the Koji build system. They are not mashed, a process which principally handles multilib, and using them can cause various problems, in addition to overloading Fedora’s development servers. It is almost always a better idea to cherry-pick new builds from Koji or Bodhi via their web interfaces or command line tools.

Repositories FAQ

なぜ、安定リリースでは updates だけが使われるのか?

上記で説明したように、 アップデートは、ブランチ のプレリリースにしろ、最終リリースにしろ、stable リリースでは、アップデートは事前に updates-testing プロセスで検証・淘汰されてから、合格したものが stable な状態のリポジトリに移動します。 最終リリースより前では、これらのアップデートは fedora リポジトリに置かれます。リリース後は、 アップデートは updates のみに置かれます。

違いの理由は、特定のFedora安定版リリースの正確な 'state' のレコードを私たちが所持したいからです。 つまり、Fedoraのリリースが Go/No-Go Meeting で行われると宣言された時点で、その時点でのリリースの状態をそのリリースの正統な定義であると私たちは見なし、その状態のレコードを保存することを私たちは望みます。 安定版リリースの場合、fedora_リポジトリを含むツリー そのレコードであり、それに含まれる _fedora リポジトリは、その安定版リリースの主要部分を形成した正確な frozen パッケージセットの正統なレコードです。

fedora リポジトリの frozen 状態を私たちは維持したいので、アップデートを直接そこに配置することは不可能なのです。 したがって、 updates リポジトリの必要性が明らかになります。リリースの frozen 状態の外側にて安定リリースの更新を配置する場所が私たちには必要です。

安定リリースが発生する前なら、このメカニズムは必要ありません。 リリースが行われたと宣言される前には、リリースの_frozen_ 状態はありません。effectively, the whole Branched development process is working towards what will become the frozen state of the release, so of course package builds for the Branched release land directly in the fedora repository.

Why is updates-testing enabled by default in pre-releases?

While Branched development releases and stable releases both use an updates-testing repository together with the Bodhi update feedback system to stage packages before they reach the release’s stable state, it is enabled by default in Branched, but not in stable releases.

The reason is that the purpose of the updates-testing system is somewhat different in each case. For stable releases, the system’s goal is to prevent broken updates reaching the general Fedora user population. In most cases, Fedora systems are expected to have the updates-testing repository disabled. Some QA testers then enable the repository on testing systems to try out the updates and provide feedback. The testers perform the job of making sure the updates are OK before they reach the general user population.

When it comes to a Branched pre-release, the expectation is that anyone who installs it wants to help test it: we effectively consider anyone running a Branched release to be a tester. The function of updates-testing is different in this case. There is not a 'general user population' of Branched users who run with updates-testing disabled, and are protected from problematic updates by the group of update testers. Instead, updates-testing in Branched serves other important functions.

The main purpose is to insulate image builds from potentially problematic changes. Branched images - nightly images, and the Alpha, Beta and GA (Final) milestone builds and their test compose and release candidate builds - are built from the stable packages, that is, only those in the fedora repository, not those in updates-testing. In this sense, updates-testing protects not a set of users, but a set of builds, from potentially destabilizing changes. Especially when we are building an Alpha, Beta or GA release, we need to be able to reduce the amount of change in the package set between composes in order to produce an image of high quality. The updates-testing mechanism allows for that: during Milestone freezes, new builds can be sent to updates-testing, but cannot move from there to stable (fedora) without special circumstances. In this way, we can work on release images while not preventing packagers from sending out builds.

For this and other less important functions, we need as much feedback as possible, so it makes sense to have all pre-release testers have updates-testing enabled by default, and encourage them to provide feedback through Bodhi.

See a typo, something missing or out of date, or anything else which can be improved? Edit this document at