From e7600cb9cfa228a4a3c083477a05277d92d17dff Mon Sep 17 00:00:00 2001 From: Allan Day Date: Jun 03 2020 16:28:12 +0000 Subject: [PATCH 1/3] 3rd party repos policy: merge wiki material At some point in the past, a more elaborate 3rd party repos policy was approved and recorded on the Workstation wiki pages: https://fedoraproject.org/wiki/Workstation/Third_party_software_Workstation_Guidelines The wiki page is more detailed than the FESCo policy and contains some useful guidance. It also applies to all Fedora editions. It therefore makes sense to merge the wiki version into fesco-docs. Three notable changes: - The previous version of the FESCo policy stated that 3rd party repos containing free software must be approved by FESCo and Fedora Legal, whereas non-free repos can be approved by working groups. The new version states that working groups can approve either type of repo. - The existing metadata rules for full 3rd party repos are applied to other repo types, including Coprs. - The wiki policy covers which type of repos can be used as the main repos of a Fedora edition. Since these aren't 3rd party repos per se, these parts of the policy have been excluded. --- diff --git a/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc b/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc index 7760fac..81f2839 100644 --- a/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc +++ b/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc @@ -1,39 +1,99 @@ -= Third party repository policy += Third Party Repository Policy -End users sometimes want to install software that is not provided by Fedora. This policy lays out the extent to which Fedora Products can make it easier for end users to do that. +Fedora's Third Party Repository Policy specifies how Fedora editions and spins can make software available to install from third parties (ie. not from Fedora). In addition to detailing the rules by which third party repositories can be included, the policy also describes requirements for how they must be managed, and guidelines for decisions that might need to be made about them. -FESCo policy is that no third party repositories can be included in Fedora, other than according to the following exceptions. +== Background & goals -== Copr Repositories +Fedora is an important participant in the world of free software, but for Fedora to have more impact we need to significantly grow our user base relative to its current size. By making Fedora easier to use, and lowering the threshold for users to get the software they need, we can accelerate the growth of the Fedora community. This will ensure that we are in the best possible position to spread the values and goals of the Fedora project. -Fedora allows contributors to build rpms and host the output in some repositories on our servers. These are known as Copr repositories. Packages in these repositories are not held to the same packaging standards as packages in the Main Fedora Repositories but they are all held to the same Licensing and Legal requirements. Fedora Legal has the authority to remove packages from the Copr repositories or have problematic Copr repositories removed as Red Hat is liable for any legal issues that may arise here. Due to this relationship, we are a little more flexible in our policy for Copr repositories than other third party repositories. +This policy is motivated by: -* The COPR Repositories can provide RPMS with .repo files pointing to themselves because Red Hat is the provider and assumes liability -* It is permissible to ship RPM packages containing .repo files that point to COPR repositories in the Fedora package collection under the following conditions per link:https://fedorahosted.org/fesco/ticket/1421[FESCo decree]: -** The repo file has the setting `enabled=0`. This means that yum, dnf and other tools cannot install software from this repository without a manual step (such as `--enablerepo=`) -** The repo file has the setting `enabled_metadata=1`. This means that some tools can optionally retrieve the metadata from this repository to provide a list of its contents to the user. The option is not used by yum or dnf. +* Recurring negative points when Fedora is reviewed, particularly but not exclusively regarding Fedora Workstation +* Feedback exercises such as link:https://blogs.gnome.org/uraeus/2015/04/20/fedora-workstation-more-than-the-sum-of-its-parts/[this blog post], which have asked users why they have not switched to Fedora +* Evidence that a large proportion of our users link:https://eischmann.wordpress.com/2015/07/31/most-popular-web-browsers-among-fedora-users/[run third party software] on Fedora -Application installers in the main Fedora repositories may search COPR repos for applications to install as long as they explicitly ask the user to enable the copr repository as noted in the introductory section. +The policy aims to make a wide range of software available to Fedora users in a easily consumable format, while ensuring that that software is clearly labelled, so users are fully informed about the software that they are installing. -== Other Repositories with only free (libre) software +== Third party repository packages -Of course, Fedora doesn't have the only software repositories that contain free (libre) software. There are other third party repositories that Fedora users want to use. Since Red Hat has no relationship with these repositories as it does with Copr repositories, allowing things in Fedora to point users to these repositories would represent a new legal liability. Fedora Legal would need to audit the packages in these repositories for legal problems both when the repositories are initially approved and on an ongoing basis (as the software in the repositories is updated, Fedora Legal would need to check that the new versions of packages in the repository remained legally okay for us to point people at.) For this reason, the rules for including a non-Copr third party repository are more strict than for Copr repos. +Each edition or spin that wishes to include third party repositories must create a clearly named RPM package to include those repository pointers. An edition or spin is free to include the repository definition of one of the other editions if preferred. There should only be one third party repository package, to minimize the risk of install conflicts. As an example, in the Fedora Workstation edition, this package is called `fedora-workstation-repositories`. -* Third party repositories that host diverse pieces of software (a repository like Fedora before it became a Red Hat community project, for instance) cannot be searched or enabled. This is because it would simply be too much work for Fedora Legal to audit such a repository. -* Repositories that enable a specific piece of free software may be shipped if the repo file has the `enabled=0` and `enabled_metadata=0` settings. They must be approved by both FESCo and Fedora Legal first. -* Fedora Legal is not limited to simply evaluating the repositories on Legal criteria. Because they are responsible for auditing the third party repositories on an ongoing basis, they have discretion to say no for other reasons including (but not limited to) simply not having time to take on the auditing of more repositories. -* FESCo and Fedora Legal can remove approval as well as grant it. This is due in part to the work that ongoing maintenance represents to Fedora Legal and also to the fact that package updates in the repositories could mean we no longer want to point to them. +=== Adding and monitoring of third-party repositories -Application installers in the main Fedora repositories must explicitly ask the user to enable the third party repository in order to search its content or install from it. +Third party repositories must be approved by an active Fedora working group or SIG, or by FESCo. Groups who approve the inclusion of third party repositories must have a documented process which allows for community input, and which produces a traceable history for each decision (for example, a ticket or other record). -== Repositories with non-free (libre) software +A working group must regularly review the repositories included in its third party repository list, in order to identify and correct issues that might arise. -Repositories that contain non-free software may be offered to users under the following conditions: +=== Inclusion requirements for third-party repositories -* Users must be presented with clear information about Fedora provided/Libre software vs Non-free/3rd party software. +Repositories that are included in a spin or edition's third-party repository list must conform to the following requirements: -* Users must explicitly opt in to such repositories after the information is presented to them. +* Just as with any software hosted by Fedora, third party repositories must not contain material that poses undue legal risk for the Fedora Project or its sponsors. This includes, but is not limited to, software with known patent issues, copyright issues or software tailored for conducting illegal activities. Fedora working groups should evaluate if a proposed addition or provider poses a significant risk, and if in doubt confer with Fedora Legal for advice. +* The repository list may include Fedora-hosted Copr repositories, in addition to those that are hosted externally. +* Working groups should ensure that the software included in any third party repository is reliable. While a formal SLA (Service Level Agreement) may not exist, the repository is expected to be something Fedora can rely upon. Working groups should be informed of changes in ownership of third party repositories. +* Changes should not impact on other Fedora editions or spins. For example, Fedora Workstation will populate the `fedora-workstation-repositories` package and include it in the workstation's comps group, but that doesn't mean that other editions or spins must do the same. +* Third party repositories that host diverse pieces of software (a repository like Fedora before it became a Red Hat community project, for instance) cannot be included. This is because it would be too much work for Fedora Legal to audit such a repository. +* Repo files must be configured with the `enabled=0` and `enabled_metadata=0` settings. Each user must explicitly enable third-party repositories in order to view their contents and install from them. The third-party nature of the repository must be clear to the user when they enable it, as should the non-free status of its content, if relevant. -* Non free software repositories must be approved by a active Fedora Working Group (for an edition), or FESCO (for all other deliverables) and are subject to the same critera as the section above on other free software repositories (ie, permission may be revoked, repositories with many different applications will be rejected as too difficult to police, etc) +=== Software labelling and metadata -Non-free software may not be presented to the user without explicit user enablement in any Fedora Edition or Spin +Users should be able to decide what software to install via clear labelling of that software. In particular, third party and non-free software should be clearly identifiable to users through software management tools, prior to installation. For Fedora Workstation, this requirement applies to GNOME Software, the primary software installer for the desktop. For other editions and tools, the maintainers of the primary software management tools should work with FESCo to decide how to ensure adequate software labelling. + +== Software inclusion requirements + +The software that is included in each third-party repository must conform to the following requirements. + +=== Software packaged as RPMs + +Requirements for software packaged using RPM: + +* Applications that ship as RPMs should conform with link:https://fedoraproject.org/wiki/How_to_create_an_RPM_package[Fedora's RPM guidelines] as closely as possible. However, while this is best practice, it is not a hard requirement. (This more relaxed approach to RPM packaging is intended to allow software to be included for whom it is difficult to conform to Fedora's packaging guidelines.) +* Software must be included in a DNF repository as described in the link:https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/package-management/DNF/[Fedora System Administrators Guide]. +* Repository can contain multiple applications. However, third parties are strongly recommended to ship their software in single application repositories as it will greatly increase chances of repository being accepted for inclusion. This minimizes the risk of "collateral damage" if one piece of software must be de-listed from Fedora temporarily or permanently for legal or other reasons. +* Repositories that mix types of software or applications are strongly discouraged. For example, a mixture of desktop and server software. +* RPM packages must not require or recommend packages containing a .desktop file, unless they are add-ons for that package with appropriate AppStream data. Amongst other things, this is intended to prevent application stacks being dragging into the system in a way that confuses users. +* RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories. + +=== Software packaged using other formats + +The Fedora project will likely want to offer software in formats beyond those mentioned above in the future. If those formats have special policy requirements, this policy document will require revision. However, requirements for these formats may be covered by the rules for registries below. + +=== Software management tools + +Software packages can contain mechanisms or systems for installing further software packages. Examples include Steam, Firefox, Chrome, Moby, Maven, NPM, PyPi, and Rubygems.org. Requirements for these software management tools: + +* The software they provide must conform to the legal requirements outlined above. +* Their software should not interfere with normal operation of the system. This means that the software should not overwrite parts of the system or cause issues with the core functionality of the system. +* It should be possible for Fedora's main software management tools to track or remove the software that is installed with these third-party tools. For example, GNOME Software should be able to track and remove games installed using Steam. + +== Replacements and duplicates + +Guidelines for third-party repositories which include software that is already present in the main Fedora repositories. + +=== Replacing a different package format + +A package may replace a package that is provided in a different format. For instance, a Flatpak may replace an RPM or set of RPMS. If both packages are supplied by the same provider, then this can be done at the provider's discretion, as long as a reasonable effort is made to provide a smooth transition for users. + +If there are different providers who disagree about which package should be the primary offering in Fedora (or a specific Edition), the new package's provider must file a ticket with FESCo asking to replace the previous package. FESCo will then try to mediate, and if no agreement is reached FESCo must decide which package to use. + +When deciding between different versions of a software package, it is suggested that preference be given to packages that: + +* are more closely aligned with Fedora the policies and goals (including those of specific editions) +* are from an upstream project or company +* are from experienced or long-term Fedora contributors +* are of greater technical quality + +=== Adding duplicate packages + +In some circumstances, it is possible to offer multiple varieties of the same software, such as to make different versions available, or make the software available in different package formats. + +In the case of graphical applications, approval must be given by a relevant working group in order for duplicates to be included. (This is in order to prevent the multiplication of versions of the same software.) If a package affects multiple working groups, FESCo can be asked to mediate. + +== Maintaining a third-party repository + +Those who are responsible for a repository which is included as a third party repository should notify the Fedora project if: + +* the repository ceases to be maintained, or will cease to be maintained in the future +* the contents of the repository changes, either in terms of the software included, or how it is licensed + +Fedora may also define agreements with third-party maintainers. From 07853107c65cbc2f62d2e79bc562b18bd0a673f6 Mon Sep 17 00:00:00 2001 From: Allan Day Date: Jun 03 2020 16:33:09 +0000 Subject: [PATCH 2/3] 3rd party repos policy: abstract the diverse repos clause The policy states that 3rd party repos shouldn't include "diverse repos". The principle here is that Fedora should retain control of the software that's being made available, as opposed to enabling repos that are out of our control and whose behaviour is risk-prone. It is helpful to restate this "diverse repos" clause in a more generic manner, in order to enable other mechanisms for managing 3rd party repos, while remaining true to the intent of the policy. For example, a working group could use a whitelist to control which software is made available from a larger repository. --- diff --git a/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc b/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc index 81f2839..d6bdfe5 100644 --- a/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc +++ b/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc @@ -32,7 +32,7 @@ Repositories that are included in a spin or edition's third-party repository lis * The repository list may include Fedora-hosted Copr repositories, in addition to those that are hosted externally. * Working groups should ensure that the software included in any third party repository is reliable. While a formal SLA (Service Level Agreement) may not exist, the repository is expected to be something Fedora can rely upon. Working groups should be informed of changes in ownership of third party repositories. * Changes should not impact on other Fedora editions or spins. For example, Fedora Workstation will populate the `fedora-workstation-repositories` package and include it in the workstation's comps group, but that doesn't mean that other editions or spins must do the same. -* Third party repositories that host diverse pieces of software (a repository like Fedora before it became a Red Hat community project, for instance) cannot be included. This is because it would be too much work for Fedora Legal to audit such a repository. +* Working groups and SIGs should maintain close control over the software that is made available through third party repositories, in order to prevent unvetted software being made available to Fedora users. As part of this, third party repositories should be managed in such a way that Fedora Legal can easily audit them at any time. This implies that third party repositories should be limited to including small numbers of packages, or that measures should be put in place to limit which packages are made available from a particular repository. * Repo files must be configured with the `enabled=0` and `enabled_metadata=0` settings. Each user must explicitly enable third-party repositories in order to view their contents and install from them. The third-party nature of the repository must be clear to the user when they enable it, as should the non-free status of its content, if relevant. === Software labelling and metadata From bdf5cf33be394f50f9fe588735b14da97d3d162d Mon Sep 17 00:00:00 2001 From: Allan Day Date: Jul 20 2020 11:54:27 +0000 Subject: [PATCH 3/3] 3rd party repos policy: respond to feedback Respond to feedback from FESCo in PR 32: - Stronger framing at the beginning of the document, to clarify the scope of the policy. Move the reference to Coprs here, which is more logical. - Software management tools section - clarify that it's only desktop apps that are required to show up in the desktop software manager. This hopefully clarifies the Steam example. - Clarify that the software management tools section only relates to tools provided by 3rd party repos. As such, remove the reference to Rubygems, NPM and so on - we expect those to come from the official repos. - Tweak the "software labelling" clause to make it clearer. - Update the link to the packaging guidelines. - Rewrite the duplicates and replacements section, to make it clear that: - Duplicates should be parallel-installable - Replacements are mostly just for apps - Replacements are only for when the main distribution channel is changed for a piece of software --- diff --git a/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc b/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc index d6bdfe5..1a6f438 100644 --- a/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc +++ b/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc @@ -1,6 +1,8 @@ = Third Party Repository Policy -Fedora's Third Party Repository Policy specifies how Fedora editions and spins can make software available to install from third parties (ie. not from Fedora). In addition to detailing the rules by which third party repositories can be included, the policy also describes requirements for how they must be managed, and guidelines for decisions that might need to be made about them. +A third party repository is any software repository which isn't officially maintained by the Fedora project, including Coprs that are hosted on Fedora infrastructure, as well as repositories that are hosted outside of Fedora. + +This policy sets out the conditions under which Fedora editions and spins can include these third party repositories and make them available to their users. It also describes requirements for how they must be managed, and guidelines for decisions that might need to be made about them. == Background & goals @@ -14,32 +16,32 @@ This policy is motivated by: The policy aims to make a wide range of software available to Fedora users in a easily consumable format, while ensuring that that software is clearly labelled, so users are fully informed about the software that they are installing. -== Third party repository packages +== Third party repository distribution -Each edition or spin that wishes to include third party repositories must create a clearly named RPM package to include those repository pointers. An edition or spin is free to include the repository definition of one of the other editions if preferred. There should only be one third party repository package, to minimize the risk of install conflicts. As an example, in the Fedora Workstation edition, this package is called `fedora-workstation-repositories`. +Third party repositories should only be distributed in a clearly named RPM package that includes the third party repository definitions. As an example, in the Fedora Workstation edition, this package is called `fedora-workstation-repositories`. To minimize the risk of install conflicts, there should only be one third party repository package. -=== Adding and monitoring of third-party repositories +If they fulfill the requirements set out in this policy, third party repository definitions can be included in an edition or spin's install media. However, all repository files must be configured with the `enabled=0` and `enabled_metadata=0` (or equivalent) settings. Each user must explicitly enable third-party repositories in order to view their contents and install from them. The third-party nature of the repository must be clear to the user when they enable it, as should the non-free status of its content, if relevant. -Third party repositories must be approved by an active Fedora working group or SIG, or by FESCo. Groups who approve the inclusion of third party repositories must have a documented process which allows for community input, and which produces a traceable history for each decision (for example, a ticket or other record). +An edition or spin is free to include the third party repository definitions of one of the other editions if preferred. -A working group must regularly review the repositories included in its third party repository list, in order to identify and correct issues that might arise. +== Key requirements for third-party repositories -=== Inclusion requirements for third-party repositories +Third party repositories must be approved by an active Fedora working group or SIG, or by FESCo. Groups who approve the inclusion of third party repositories must have a documented process which allows for community input, and which produces a traceable history for each decision (for example, a ticket or other record). -Repositories that are included in a spin or edition's third-party repository list must conform to the following requirements: +Additionally, repositories that are included in an edition or spin's third-party repository list must conform to the following requirements: * Just as with any software hosted by Fedora, third party repositories must not contain material that poses undue legal risk for the Fedora Project or its sponsors. This includes, but is not limited to, software with known patent issues, copyright issues or software tailored for conducting illegal activities. Fedora working groups should evaluate if a proposed addition or provider poses a significant risk, and if in doubt confer with Fedora Legal for advice. -* The repository list may include Fedora-hosted Copr repositories, in addition to those that are hosted externally. * Working groups should ensure that the software included in any third party repository is reliable. While a formal SLA (Service Level Agreement) may not exist, the repository is expected to be something Fedora can rely upon. Working groups should be informed of changes in ownership of third party repositories. * Changes should not impact on other Fedora editions or spins. For example, Fedora Workstation will populate the `fedora-workstation-repositories` package and include it in the workstation's comps group, but that doesn't mean that other editions or spins must do the same. * Working groups and SIGs should maintain close control over the software that is made available through third party repositories, in order to prevent unvetted software being made available to Fedora users. As part of this, third party repositories should be managed in such a way that Fedora Legal can easily audit them at any time. This implies that third party repositories should be limited to including small numbers of packages, or that measures should be put in place to limit which packages are made available from a particular repository. -* Repo files must be configured with the `enabled=0` and `enabled_metadata=0` settings. Each user must explicitly enable third-party repositories in order to view their contents and install from them. The third-party nature of the repository must be clear to the user when they enable it, as should the non-free status of its content, if relevant. + +A working group must regularly review the repositories included in its third party repository list, in order to identify and correct issues that might arise. === Software labelling and metadata -Users should be able to decide what software to install via clear labelling of that software. In particular, third party and non-free software should be clearly identifiable to users through software management tools, prior to installation. For Fedora Workstation, this requirement applies to GNOME Software, the primary software installer for the desktop. For other editions and tools, the maintainers of the primary software management tools should work with FESCo to decide how to ensure adequate software labelling. +Third party and non-free software should be clearly identifiable to users through software management tools, prior to installation. For Fedora Workstation, this requirement applies to GNOME Software, the primary software installer for the desktop. For other editions and tools, the maintainers of the primary software management tools should work with FESCo to decide how to ensure adequate software labelling. -== Software inclusion requirements +== Third party software requirements The software that is included in each third-party repository must conform to the following requirements. @@ -47,12 +49,12 @@ The software that is included in each third-party repository must conform to the Requirements for software packaged using RPM: -* Applications that ship as RPMs should conform with link:https://fedoraproject.org/wiki/How_to_create_an_RPM_package[Fedora's RPM guidelines] as closely as possible. However, while this is best practice, it is not a hard requirement. (This more relaxed approach to RPM packaging is intended to allow software to be included for whom it is difficult to conform to Fedora's packaging guidelines.) +* Applications that ship as RPMs should conform with link:https://docs.fedoraproject.org/en-US/packaging-guidelines/[Fedora's RPM guidelines] as closely as possible. However, while this is best practice, it is not a hard requirement. (This more relaxed approach to RPM packaging is intended to allow software to be included for whom it is difficult to conform to Fedora's packaging guidelines.) * Software must be included in a DNF repository as described in the link:https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/package-management/DNF/[Fedora System Administrators Guide]. * Repository can contain multiple applications. However, third parties are strongly recommended to ship their software in single application repositories as it will greatly increase chances of repository being accepted for inclusion. This minimizes the risk of "collateral damage" if one piece of software must be de-listed from Fedora temporarily or permanently for legal or other reasons. * Repositories that mix types of software or applications are strongly discouraged. For example, a mixture of desktop and server software. * RPM packages must not require or recommend packages containing a .desktop file, unless they are add-ons for that package with appropriate AppStream data. Amongst other things, this is intended to prevent application stacks being dragging into the system in a way that confuses users. -* RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories. +* RPM packages in a third party repository must replace packages provided by official Fedora repositories, nor should the break dependencies between those packages. === Software packaged using other formats @@ -60,19 +62,33 @@ The Fedora project will likely want to offer software in formats beyond those me === Software management tools -Software packages can contain mechanisms or systems for installing further software packages. Examples include Steam, Firefox, Chrome, Moby, Maven, NPM, PyPi, and Rubygems.org. Requirements for these software management tools: +Third party repositories can include software which is itself a mechanism or system for installing further software packages. Potential examples include Steam and Chrome. When a software management tool is provided by a third party repositoriy, it must conform to the following requirements: * The software they provide must conform to the legal requirements outlined above. * Their software should not interfere with normal operation of the system. This means that the software should not overwrite parts of the system or cause issues with the core functionality of the system. -* It should be possible for Fedora's main software management tools to track or remove the software that is installed with these third-party tools. For example, GNOME Software should be able to track and remove games installed using Steam. +* If a third party repo provides a software management tool which installs desktop applications, it should be possible for the desktop software management app to track or remove those apps. For example, GNOME Software should be able to track and remove games installed using Steam. + +== Duplicates and replacements + +Third party repositories can be used to supplement official Fedora software and, in some limited cases, be used to replace software that is included in the official Fedora repositories. -== Replacements and duplicates +=== Duplicates -Guidelines for third-party repositories which include software that is already present in the main Fedora repositories. +A third party repository can include additional versions of software that is contained in the official Fedora repositories. This can be done to make a different version available or to make the software available in a different format. In each case, installing the version from the third party repository should not replace any installed version from the official repositories. -=== Replacing a different package format +In the case of graphical applications, approval must be given by a relevant working group in order for additional versions to be included. (This is in order to prevent the multiplication of versions of the same software.) If a package affects multiple working groups, FESCo can be asked to mediate. -A package may replace a package that is provided in a different format. For instance, a Flatpak may replace an RPM or set of RPMS. If both packages are supplied by the same provider, then this can be done at the provider's discretion, as long as a reasonable effort is made to provide a smooth transition for users. +=== Replacements + +Software which is included in the official Fedora repositories can only be replaced by a third party repository, under the following circumstances: + +* The affected software must not form part of the system or critical features. The general expectation is that replacements will typically only happen for applications. +* Replacements should only take place when it is decided that the third party repository is to become the primary distribution mechanism for that piece of software. Typically this will involve the removal of the software from Fedora's official repositories. +* An effort should be made to ensure a smooth transition for existing users of the software, as the distribution channel is switched. + +The main example of replacement is providing a desktop application as a third party Flatpak as opposed to an RPM in the official repositories. + +==== Competing versions If there are different providers who disagree about which package should be the primary offering in Fedora (or a specific Edition), the new package's provider must file a ticket with FESCo asking to replace the previous package. FESCo will then try to mediate, and if no agreement is reached FESCo must decide which package to use. @@ -83,12 +99,6 @@ When deciding between different versions of a software package, it is suggested * are from experienced or long-term Fedora contributors * are of greater technical quality -=== Adding duplicate packages - -In some circumstances, it is possible to offer multiple varieties of the same software, such as to make different versions available, or make the software available in different package formats. - -In the case of graphical applications, approval must be given by a relevant working group in order for duplicates to be included. (This is in order to prevent the multiplication of versions of the same software.) If a package affects multiple working groups, FESCo can be asked to mediate. - == Maintaining a third-party repository Those who are responsible for a repository which is included as a third party repository should notify the Fedora project if: