Fedora Repositories

For stable releases, fedora represents the frozen release state. 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. The package set it contains never changes after that time. It represents the stable state of a stable release in conjunction with updates repository.

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, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-41&arch=x86_64 will return mirrors for the x86_64 fedora repository for release 41.

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 updates-testing activation, 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, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-42&arch=x86_64 will return mirrors for the x86_64 fedora repository for release 42.

The updates-testing repository exists for Branched releases after the Bodhi enabling point, and for stable releases. 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).

These builds are sometimes referred to as update candidates, and are reviewed with the Bodhi update feedback tool, 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.

The updates-testing repository is enabled by default for Branched releases, but disabled by default for stable releases. 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. Running dnf distro-sync or re-enabling the updates-testing repository will both usually alleviate the issue; it is up to the individual user whether they wish to continue using the updates-testing repository after the stable release or not.

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, https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f41&arch=x86_64 will return mirrors for the x86_64 updates-testing repository for release 41.

In Rawhide - Fedora’s rolling release repository, from which release are Branched before finally going stable - rawhide is the only repository. All package builds are sent there. It is represented for DNF in the fedora-rawhide.repo file in the repository path. For any system running Rawhide, it should be enabled. For any other system, it should not.

The rawhide repositories for the various primary architectures can be found in the directory on the mirrors, and can also be queried from MirrorManager. For instance, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 will return mirrors for the x86_64 fedora repository for Rawhide.

It is not unusual to see references to the 'stable repository', but this is something of a misnomer. 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.

For Branched releases, the stable state is represented solely by the current contents of the fedora repository (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).

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

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.

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 https://pagure.io/fedora-docs/quick-docs.