In Branched releases - the state a release is in between branching from [[Releases/Rawhide|Rawhide]] and stable release, see [[Releases/Branched|Branched]] for more details - the ''fedora'' repository alone represents the release's ''stable'' state. The [[#updates|''updates'' repository]] for Branched releases is not used until they become stable. Before the [[Change deadlines|Alpha change deadline]], package builds for the Branched release are sent directly to this repository. After the Alpha change deadline, package builds that pass the [[Updates Policy]] move from [[#updates-testing|the ''updates-testing'' repository]] to this repository.

+

In Branched releases - the state a release is in between branching from [[Releases/Rawhide|Rawhide]] and stable release, see [[Releases/Branched|Branched]] for more details - the ''fedora'' repository alone represents the release's ''stable'' state. The [[#updates|''updates'' repository]] for Branched releases is not used until they become stable. Before the [[Updates Policy#Bodhi enabling|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|the ''updates-testing'' repository]] to this repository.

The Branched ''fedora'' repositories for the various primary [[Architectures|architectures]] can be found in the {{filename|/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-{{FedoraVersionNumber|next}}&arch=x86_64 will return mirrors for the x86_64 ''fedora'' repository for {{FedoraVersion|long|next}}.

The Branched ''fedora'' repositories for the various primary [[Architectures|architectures]] can be found in the {{filename|/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-{{FedoraVersionNumber|next}}&arch=x86_64 will return mirrors for the x86_64 ''fedora'' repository for {{FedoraVersion|long|next}}.

Line 38:

Line 38:

== The ''updates-testing'' repository ==

== The ''updates-testing'' repository ==

−

The ''updates-testing'' repository exists for Branched releases after the [[Change deadlines|Alpha change deadline]], and for stable releases. It is represented for [[Yum]] or [http://dnf.baseurl.org/ DNF] in the {{filename|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|''fedora'']] repository or the [[#updates|''updates'']] repository, respectively).

+

The ''updates-testing'' repository exists for Branched releases after the [[Updates Policy#Bodhi enabling|Bodhi enabling point]], and for stable releases. It is represented for [[Yum]] or [http://dnf.baseurl.org/ DNF] in the {{filename|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|''fedora'']] repository or the [[#updates|''updates'']] repository, respectively).

These builds are sometimes referred to as ''update candidates'', and are reviewed with the [[Bodhi]] update feedback tool, according to the [[QA:Update_feedback_guidelines|update feedback guidelines]].

These builds are sometimes referred to as ''update candidates'', and are reviewed with the [[Bodhi]] update feedback tool, according to the [[QA:Update_feedback_guidelines|update feedback guidelines]].

Line 44:

Line 44:

The [[Updates_Policy]] defines the rules for marking update candidates as ''stable''. The [[QA:Updates_Testing|QA updates-testing page]] provides some information for testers on using this repository. The [[Package_update_HOWTO|package update guidelines]] provide information for packagers on submitting builds to ''updates-testing'' and to ''stable''.

The [[Updates_Policy]] defines the rules for marking update candidates as ''stable''. The [[QA:Updates_Testing|QA updates-testing page]] provides some information for testers on using this repository. The [[Package_update_HOWTO|package update guidelines]] provide 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 [[Change deadlines|Final change deadline]] 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 {{command|yum 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'' repository is enabled by default for Branched releases, but disabled by default for stable releases. The switchover is made around the time of the [[Release freezes|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 {{command|yum 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 {{filename|/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-f{{FedoraVersionNumber}}&arch=x86_64 will return mirrors for the x86_64 ''updates-testing'' repository for {{FedoraVersion|long}}.

The ''updates-testing'' repositories for both Branched and stable releases can be found in the {{filename|/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-f{{FedoraVersionNumber}}&arch=x86_64 will return mirrors for the x86_64 ''updates-testing'' repository for {{FedoraVersion|long}}.

Line 50:

Line 50:

== ''stable'' is not a repository ==

== ''stable'' is not a repository ==

−

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 [[Releases/Branched|Branched]] releases post-[[Change deadlines|Alpha change deadline]], and stable releases. It consists of package builds that were part of [[Releases/Rawhide|Rawhide]] at the time they Branched, package builds sent directly to the Branched [[#fedora|''fedora'']] repository between the branch point and the Alpha change deadline, and package builds that passed the [[Updates Policy]] and moved from [[#updates-testing|''updates-testing'']] after the Alpha change deadline.

+

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 [[Releases/Branched|Branched]] releases post-[[Updates Policy#Bodhi enabling|Bodhi enabling]] and for stable releases. It consists of package builds that were part of [[Releases/Rawhide|Rawhide]] at the time they Branched, package builds sent directly to the Branched [[#fedora|''fedora'']] repository between the branch point and the ''Bodhi enabling point'', and package builds that passed the [[Updates Policy]] and moved from [[#updates-testing|''updates-testing'']] after the ''Bodhi enabling point''.

For Branched releases, the ''stable'' state is represented solely by the current contents of the [[#fedora|''fedora'']] repository (and, arguably, the [[#bleed|''bleed'']] repository, but that is a small case).

For Branched releases, the ''stable'' state is represented solely by the current contents of the [[#fedora|''fedora'']] repository (and, arguably, the [[#bleed|''bleed'']] repository, but that is a small case).

For stable releases, the ''stable'' state is represented by the contents of the [[#fedora|''fedora'']] repository combined with the contents of the [[#updates|''updates'']] repository.

For stable releases, the ''stable'' state is represented by the contents of the [[#fedora|''fedora'']] repository combined with the contents of the [[#updates|''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, the ''stable'' repository for a release - whichever literal repository that is (see above).

== Installation and [[Fedora.next|Product]] repositories / trees ==

== Installation and [[Fedora.next|Product]] repositories / trees ==

Line 77:

Line 79:

=== The ''bleed'' repository ===

=== The ''bleed'' repository ===

−

The ''bleed'' repository exists for a single purpose: during milestone freezes (after the [[Change deadlines|change deadline]] for a milestone release), 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|''fedora'']] repository. In other words, it contains packages explicitly required in TC/RC [[QA:SOP_compose_request|compose requests]].

+

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|''fedora'']] repository. In other words, it contains packages explicitly required in TC/RC [[QA:SOP_compose_request|compose requests]].

The ''bleed'' repository can be found [http://kojipkgs.fedoraproject.org/mash/bleed/ 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|''updates-testing'']] repository.

The ''bleed'' repository can be found [http://kojipkgs.fedoraproject.org/mash/bleed/ 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|''updates-testing'']] repository.

Revision as of 23:04, 25 September 2014

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

The fedora repository exists for all Fedora releases after they have Branched from Rawhide. It is represented for Yum or DNF in the fedora.repo file in the repository path. For any Fedora installation, this repository will be enabled by default, and should usually remain so.

The fedora repository in stable releases

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 the updates repository.

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 the updates-testing repository to this repository.

The rawhide repository

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 Yum or 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 updates repository

The updates repository exists for Branched and stable releases, but is only populated and used for stable releases. 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.

For stable releases, updates together with fedora represents the current stable state of the release. 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.

The updates-testing repository

The updates-testing repository exists for Branched releases after the Bodhi enabling point, and for stable releases. It is represented for Yum or 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-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 yum 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.

stable is not a repository

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, the stable repository for a release - whichever literal repository that is (see above).

The repositories referred to above are neither associated with a specific Fedora.nextProduct, 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-33&arch=x86_64 will return mirrors for the x86_64 current installation repository for Fedora 33 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 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 latestrepositories 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.