Repositories/ja

In other languages: English (en) français (fr) 日本語 (ja) [edit]

このページでは、Fedoraの様々なリリースでのリポジトリの内容について説明します。また、リポジトリどうしの関係や、そのリポジトリに入ってるパッケージの特徴についても説明します。

リポジトリ fedora

リポジトリ fedora は、ほぼ全てのリリースのために存在しています。ただし、Rawhide（ローハイド）というリリースを除きます。ローハイドから枝分かれ（ブランチ）されたBranchedというリリースも、リポジトリ fedoraの対象として含まれます。fedora.repo ファイルにあるリポジトリパス (repository path) に従って Yum または DNF が取りにいきます。 どんな Fedora をインストールしても、このリポジトリ (リポジトリ fedora)は標準で有効化されており、ユーザー操作によって無効化しないかぎり、そのまま有効化設定が残り続けます。

安定リリースでの fedora リポジトリ

安定リリースでは、 fedora リポジトリの状態がリリース当時の状態に凍結 (frozen) されています。 It is a part of the frozen tree that is created by Release Engineering when a release is approved at a Go_No_Go_Meeting. パッケージセットはそれ以降は、決して変更されません。なので updates リポジトリ に接続すれば、システムを安定リリースの安定 (stable) 状態にさせられます。

安定リリースについては、ミラーサーバーの /fedora/linux/releases/XX/Everything ディレクトリ (XX にはリリース番号が入る)にて、さまざまな主要なアーキテクチャ（アーキテクチャとは「x86_64」とか「i386」とかのこと）のための fedora リポジトリが見つかります。また、MirrorManager に問いかけても、見つかります。たとえば、 https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-41&arch=x86_64 に問いかけると、すぐに x86_64 fedora リポジトリ Fedora 41 ミラーの一覧を返します。

Branched リリースでの fedora リポジトリ

ブランチリリース - (これはRawhideまたは安定板などから枝分かれ(branch)した状態というリリースです。詳細は Branched をご覧ください) - fedora リポジトリ はリリースの安定(stable)な状態だけに対応します。 ブランチリリースでは updates リポジトリ にソフトウェアは用意されてません（※訳注　ブランチリリースはまだ安定してないなどの理由により、リポジトリ updates-testing などが代わりに使用されたりする）。 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 the updates-testing repository to this repository.

ブランチについては、ミラーサーバーの /fedora/linux/development/XX ディレクトリ (XX にはリリース番号が入る)にて、さまざまな主要なアーキテクチャ（アーキテクチャとは「x86_64」とか「i386」とかのこと）のための fedora リポジトリが見つかります。また、MirrorManager に問いかけても、見つかります。たとえば、 https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-42&arch=x86_64 に問いかけると、すぐに x86_64 fedora リポジトリ Fedora 42 ミラーの一覧を返します。

updates リポジトリ

updates リポジトリとは、ブランチリリースおよび安定リリースのためのものですが、もっぱら安定リリースのために使用されてるリポジトリです。 It is represented for Yum or 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. For any Fedora installation, this repository will be enabled by default, and should usually remain so.

(※暫定訳:　ファイル fedora-updates.repo に書いてあるリポジトリパス (repository path) に従って、Yum または DNF が、ソフトウェアを取りに行きます。通常の Fedora インストールでは、このリポジトリ (updates) が標準で有効化されてるはずですし、残り続けてるはずです。)

安定リリースにおいての updates リポジトリとは、システムを fedora を安定なうえでの最近の状態へと更新します（つまり、不安定なソフトウェアは、たとえ新しくてもインストールしないという事）。Package builds that pass the Updates Policy move from the updates-testing repository to this repository. This difference from Branched is a result of the need to maintain a precise representation of the initial, 'frozen' state of a stable release.

安定リリースにおいて、ミラーサーバーの /fedora/linux/updates/XX ディレクトリ (XX にはリリース番号が入る)にて、 さまざまな主要なアーキテクチャ（アーキテクチャとは「x86_64」とか「i386」とかのこと）のための updates リポジトリが見つかります。また、MirrorManager に問いかけても、見つかります。たとえば、 https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f41&arch=x86_64 に問いかけると、すぐに x86_64 fedora リポジトリ Fedora 41 ミラーの一覧を返します。

updates-testing リポジトリ

updates-testing リポジトリとは、Bodhi enabling point 後のブランチリリースのため、または安定リリースのために用意されています。fedora-updates-testing.repo ファイルにあるリポジトリパスに従って、Yum または DNF が取りに行きます。 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).

ここのビルド物は アップデート候補でして、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 guidelines provide information for packagers on submitting builds to updates-testing and to stable.

updates-testing リポジトリはブランチリリースでは標準で有効化されています。しかし、安定リリースでは標準では無効化されています。 The switchover is made around the time of the Final Freeze for each release. Testers moving from Branched to stable may encounter errors running updates around this time, caused by dependency mismatches between packages already installed from the now-disabled updates-testing repository. コマンド dnf distro-sync (または yum で同様のコマンド)を実行するか、それとも再度 updates-testing リポジトリを有効化するかは、どちらを選ぶかはあなた次第の問題です。 it is up to the individual user whether they wish to continue using the updates-testing repository after the stable release or not.

ミラーサーバーの /fedora/linux/updates/testing/XX ディレクトリ (XX にはリリース番号が入る)にて、 ブランチリリースまたは安定リリースのための、updates-testing リポジトリが見つかります。また、MirrorManager に問いかけても、見つかります。たとえば、 https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f41&arch=x86_64 に問いかけると、すぐに、Fedora 41 のための x86_64 updates-testing リポジトリのミラーの一覧を返します。

rawhide リポジトリ

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

ミラーサーバーの /fedora/linux/development/XX ディレクトリ (XX にはリリース番号が入る)にて、 fedora のための、さまざまな主要なアーキテクチャ（アーキテクチャとは「x86_64」とか「i386」とかのこと）のためのリポジトリが見つかります。また、MirrorManager に問いかけても、見つかります。たとえば、 https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-42&arch=x86_64 に問いかけると、すぐに x86_64 fedora リポジトリ Fedora 42 ミラーの一覧を返します。

stable という名のリポジトリはない

'stable repository'（安定リポジトリ）といった名称をしばしば見かけるかもしれませんが、しかし Fedora においては、それ(stable repository) は誤った名称です。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).

安定リリースにおいては、安定 (stable) 状態とは、fedora リポジトリに加えて、さらに updates リポジトリによる更新によって、システム内を最新にした状態のことです。

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).

（※暫定訳:　stable とはつまり、パッケージの状態のこと。）

Installation and Product repositories / trees

The repositories referred to above are neither associated with a specific Fedora.next 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 Fedora.next releases - Fedora 21 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, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-42&arch=x86_64 will return mirrors for the x86_64 current installation repository for Fedora 42 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 /releases/test directory (see above). They contain a subset of the full package set that is considered to define each Product (see comps for the technical details of this).

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 Yum or 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 QA:SOP_blocker_bug_process or QA:SOP_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.

よくある質問と答え (FAQ)

Why is updates only used after the stable release?

As described above, updates for both Branched pre-releases and final, 'stable' releases go through the updates-testing process before being moved to a stable repository. Before the final release, they are placed in the fedora repository. After release, they are placed in updates.

The reason for the difference is that we want to have a record of the exact 'state' of a given Fedora stable release. That is, at the time a Fedora release is declared to be done at a Go No Go Meeting, we consider the state of the release at that time to be the canonical definition of that release, and we wish to preserve a record of that state. For a stable release, the tree containing the fedora repository is that record, and the fedora repository it contains is the canonical record of the precise frozen package set that formed the main part of that stable release.

Since we wish to maintain this frozen state for the fedora repository, we cannot place updates directly into it. The necessity for the updates repository therefore becomes obvious - we need a place to put updates to stable releases that is outside the frozen state of the release.

Before a stable release occurs, this mechanism is not necessary. Before the release is declared to be done, there is no frozen state of the release: 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.

何故、プレリリース版では updates-testing が標準で有効化されてるのか？

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.

(※意訳:　理由は、各リリースごとにユーザーの目的が違うからです。つまり、プレリリース版を使うユーザーはバグ発見を目的にしてる、いわゆる「テスター」なので、よってプレリリースではupdates-testingリポジトリを有効化してるというわけです。テスターの仕事とは、リリース前に不具合（バグ）を発見しておいて、その情報をフィードバックして Fedora を修正することで、多くの一般ユーザー達が Fedora を快適に使えるようにしておく事が、テスターの仕事だからです。)

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.

(※意訳:　要するに「プレリリースのユーザー」＝「テスター」だ、と私達 Fedora コミュニティは考えています。そもそも安定リリース版の一般ユーザーが、標準では使えないように、安定リリースでは標準状態では updates-testing リポジトリが無効化されています。なぜなら updates-testing リポジトリ提供のソフトには、まだ未発見のバグがあるかもしれないので、そういう意味で、この updates-testing は不安定なソフトを提供してるリポジトリなのです。なので、この（取り扱いソフトウェアが）不安定な updates-testing リポジトリを、安定リリースから隔離するための設定が、（安定リリース版では）標準でされているわけです。)

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 (see the blocker and freeze exception processes). 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.