|
|
| (22 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| = Proposal for Revision to Fedora's Software Packaging Policies = | | = Fedora Third Party Software Packaging Policy = |
|
| |
|
| {{draft | This is a work in progress. Until this notice is removed, don't rely on this document being an accurate reflection of the ideas inside.}}
| | [https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/ Fedora's third party repository policy] is hosted by FESCo. This page used to contain an old version which was maintained by the Workstation Working Group. It is being retained mostly for historical reference. |
| | |
| == Goals ==
| |
| | |
| 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 growing our user base we hope to add to the potential contributor base for Fedora and for free software overall. By making Fedora easier to use, and lowering as much as possible the threshold for users to get the software they need, we can accelerate the growth of the Fedora community. Doing so also ensures we are in the best position possible to spread the values and goals of the Fedora project as widely as possible. Our goal is to lay the groundwork to see even more rapid growth of the Fedora user community. This proposal is motivated by:
| |
| | |
| * Recurring topics that tend to come up as negatives when Fedora is reviewed, particularly but not exclusively the Workstation;
| |
| * Feedback received through other means, such as [https://blogs.gnome.org/uraeus/2015/04/20/fedora-workstation-more-than-the-sum-of-its-parts/ this blog post] asking the community for reasons they have not switched to Fedora
| |
| * Evidence that a large proportion of our users [https://eischmann.wordpress.com/2015/07/31/most-popular-web-browsers-among-fedora-users/ run third party software] on Fedora
| |
| | |
| To achieve this goal, we want to accomplish two goals:
| |
| | |
| * Make software built and provided outside the traditional official Fedora repositories available to our users, and
| |
| * Provide Fedora repositories that contain software packaged in ways other than RPM.
| |
| | |
| The software might come in a variety of formats and conditions. This writeup is meant to provide reasoning, policy, and instructions for how this can happen. The desired outcome is to make the widest possible range of software available to Fedora users in a easily consumable format, while ensuring the software has labels and metadata that allows users to decide on the software they install. We want to ensure Fedora continues to be a strong proponent of open source software.
| |
| | |
| This proposal aims to modify the current policies defined here:
| |
| * https://fedoraproject.org/wiki/How_to_create_an_RPM_package
| |
| * https://fedoraproject.org/wiki/Third_Party_Repository_Policy
| |
| | |
| This document is not currently worded or enacted as a drop-in replacement for said policies. However, it contains a basis for editing these and related policies to conform to the new goals and rules outlined in this document.
| |
| | |
| == New Fedora Software policy outline ==
| |
| | |
| There will be two tiers of software available in Fedora:
| |
| | |
| * '''Tier One''': software packaged and hosted by the Fedora Project. This is essentially the software today packaged as RPMs and used to build the various Fedora editions. The main change to this tier is that we allow software to be packaged in other ways than RPMS, for instance Docker images or Flatpak images.
| |
| | |
| * '''Tier Two''': software hosted and packaged elsewhere, but discoverable and installable through Fedora software tooling. This software might be hosted elsewhere due to simple preference of upstream maintainer, legal restrictions, or inability to comply with Fedora software policies. An example of software in the second tier is COPRs, which are FOSS and legally unencumbered, but for example may provide alternate builds of software Fedora includes.
| |
| | |
| This proposal aims to move to a model in which, rather than judging whether software conforms to a predefined set of principles on a project level, users decide what to install via clear labelling of software. For instance, we can label any third party software with a "third party" label using GNOME Software in Fedora Workstation, relying on available metadata, to clarify that the software in question doesn't come from Fedora. For example, if Firefox was provided by Mozilla directly, it would be marked with a "third party" label to inform users they are installing software not provided by the Fedora community.
| |
| | |
| Software not deemed "free" by Fedora standards, for instance Google Chrome, would be labelled both "third party" and "nonfree" for not conforming to Fedora's definition of free. Over time further labels may be introduced to further inform users. For the Workstation edition, this labelling will be clearly visible in GNOME Software, the primary software installer for the desktop. For other editions and tools, the maintainers of said installers would need to work with FESCo to decide how to provide this labelling information in the relevant tools.
| |
| | |
| The screenshot below demonstrates current implementation in GNOME Software. '''FIXME: Missing screenshot'''
| |
| | |
| == Principles ==
| |
| | |
| While the inclusion process is one of procurement, meaning the process isn't a total free for all, we want it to be as objective and transparent as possible. The requirements on third party software providers must be easy to understand and applied in a fair and balanced manner. Below is an outline of the technical requirements and process for submitting third party applications, libraries, and tools for Fedora.
| |
| | |
| == Legal requirements ==
| |
| | |
| Just as with any software hosted by Fedora, third party software 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 or software tailored for conducting illegal activities. The Fedora working groups will evaluate if a proposed addition or provider poses a significant risk, and if in doubt confer with Fedora Legal for advice.
| |
| | |
| == Non-universal approach ==
| |
| | |
| An important principle of these changes is that they are implemented in an electable way by each individual working group or special interest group. So for example, the Fedora Workstation working group may enable a set of third party applications through GNOME Software. This should be done in a way that does not force, for instance, the desktop oriented spins to adopt the same policy, although they may do so.
| |
| | |
| For example, the Workstation will populate the fedora-workstation-repositories package and include it in the Workstation's comps group, but that doesn't mean other editions or spins must do the same.
| |
| | |
| Working groups or SIGs considering third-party applications must have a documented process which allows for community input and which produces a traceable history for each decision (e.g., a ticket or other artifact)."
| |
| | |
| == Technical requirements and Submission guidelines ==
| |
| | |
| === Rules for software packaged as RPMs ===
| |
| | |
| All applications that ship as an RPM should conform as closely as possible with the RPM Guidelines found here:
| |
| https://fedoraproject.org/wiki/How_to_create_an_RPM_package
| |
| | |
| That said, a goal of this proposal is to allow software not already available in Fedora to become available. It is often difficult for that software to fit the current packaging guidelines to be included. So while we recommend following these package guidelines as a matter of best practice, they are not a hard requirement for being made available.
| |
| | |
| The software must appear in a yum repository as described here:
| |
| https://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/sec-Creating_a_Yum_Repository.html | |
| | |
| A yum repository may contain multiple applications. However, third parties should prefer to ship their software in single application repositories. 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. A yum repository is a hard requirement for RPM packaged applications to be considered. Repositories that mix applications with different purposes are not permitted.
| |
| | |
| RPM packages must not Require or Recommend packages containing a .desktop file, unless they are add-ons for that package with appropriate AppStream data. This will prevent e.g. obscure tools used in build toolchains from dragging application stacks onto 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.
| |
| | |
| As part of proposing a package for a Fedora edition there will be a discussion about reliability of 3rd party repository, while a formal SLA (Service Level Agreement) we will still expect the repository to be something we can rely upon and that if that ever changes the owner of the repository will notify us.
| |
| | |
| === Rules for software packaged as Docker images ===
| |
| | |
| {{admon/note | TBD | Rules for Docker images will be developed by the Fedora Server and Fedora Cloud working groups.}}
| |
| | |
| === Rules for software packaged as a Flatpak ===
| |
| | |
| ==== Flatpaks hosted by Fedora (Tier One) ====
| |
| | |
| Any Flatpak hosted by Fedora must be built using the official Fedora Flatpak runtime.
| |
| | |
| {{admon/note | TBD | The official Flatpak runtime should be referenced here by URL. The Fedora flatpak is
| |
| still in development. }}
| |
| | |
| ==== Third party Flatpaks (Tier Two) ====
| |
| | |
| Third party applications are strongly recommended to use the official Flatpak runtime to avoid unneeded runtime proliferation, and to preserve users' disk space.
| |
| | |
| {{admon/note | mcatanzaro: It's ambiguous what the "official" runtime is here. We surely want third-party apps to use upstream GNOME runtimes to avoid runtime proliferation.
| |
| | |
| cschalle: mcantazaro: no we do not, for a variety of reasons, but the most screaming one being that the upstream GNOME carries no support promises and unless a very dedicated and large volunteer community arises to support it there is no chance it will become supported. The upstream GNOME one should be seen as the runtime from Git master option, which is probably mostly useful for 1st party modules in GNOME for development purposes.
| |
| | |
| This probably requires further discussion outside the wiki. We agree to encourage Flatpak as a solution for cross-distro app development. If we're also going to encourage upstreams to depend on downstream Fedora runtimes, that makes this a much tougher sell to third party developers. | |
| | |
| : I agree this needs further discussion outside the wiki. I think we should provide a Fedora runtime matching the Fedora lifecycle and make it clear to developers that this is appropriate for leading-edge fast moving applications, and encourage a CentOS-based runtime for everything else; this seems like a good place for cross-distro collaboration. --[[User:Mattdm|Mattdm]] ([[User talk:Mattdm|talk]]) 14:05, 16 June 2016 (UTC)
| |
| | |
| : Also: I strongly believe that Flatpak is unlikely to succeed without our own effort to create Flatpak-packaged applications ourselves; I expect these will be built from existing Fedora RPMs and target the Fedora runtime. Ideally, they'd go through the [[Changes/Layered_Docker_Image_Build_Service|Layered Docker Image Build Service]] and get all of the advantages that provides. [[User:Mattdm|Mattdm]] ([[User talk:Mattdm|talk]]) 16:00, 16 June 2016 (UTC)
| |
| | |
| }}
| |
| | |
| === Rules for software 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.
| |
| | |
| === Registries and similar tools ===
| |
| | |
| A first or third party package might contain mechanisms or systems for installing further applications. Examples include Steam, Firefox, Chrome, Docker, Maven, NPM, PyPi, and Rubygems.org. Software made available in such a registry must conform to the legal requirements outlined for third party applications above to be considered for inclusion. The software they provide must be packaged in a way that does not interfere with normal operation of the system, meaning the included mechanisms must not install their software in a way that overwrites system copies or injects into a system path such that it causes issues for the core functionality of the system.
| |
| | |
| The packager/provider of such registries or tools should make it possible for the main software handling tools we ship to track or remove the applications installed. So in the example of Steam, GNOME Software should be able to track or remove games installed.
| |
| | |
| === Replacing a different package format ===
| |
| | |
| A package may replace a package of a different format; for instance, an Flatpak may replace an RPM or set of RPMS. If the package provider is the same in both cases, 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.
| |
| | |
| The following principles are suggested bases for a FESCo decision in such a case. These are not in strict order, and should be weighed appropriately on a case by case basis.
| |
| | |
| * A package that more closely fits the policy and goals of Fedora (or a specific Edition) is preferred
| |
| * Packages created and maintained by the upstream project or company is preferred
| |
| * Packages from experienced or long term Fedora contributors are preferred
| |
| * Higher technical quality is preferred
| |
| | |
| | |
| {{admon/note | questions | I have a few questions here. Why are upstream packages preferred? I mean, that's nice, but if someone wants to add value by taking maintainership in Fedora, isn't that ''even better''? What about frequency of updates? That has several dimensions: on the one hand, responsiveness to security issues; on another, what about UX changes happening within a Fedora release cycle, where traditionally we have a policy of preferring to defer those for major Fedora releases? [[User:Mattdm|Mattdm]] ([[User talk:Mattdm|talk]]) 14:35, 16 June 2016 (UTC)
| |
| | |
| Christian: Well first of all no rule without exceptions of course, but I think the upstream preference comes from a wish to give application developers control of their application if want to have it. And especially in the context of Flatpaks this is probably the developers wish as they can maintain one package for all their users.
| |
| }}
| |
| | |
| === Handling duplicate/similar packages ===
| |
| | |
| It is possible under some circumstances to offer multiple varieties of the same application. For instance, a package may have a stable and a development version. In general, Fedora prefers not to offer the user a long list of varieties of the same package in software management tools, at least in the case of graphical applications. In the case of graphical applications, any packages or sets of packages beyond the first for a given application must be approved by the relevant Fedora Working Group on a case by case basis. If a package strongly affects multiple working groups, any working group other than the one proposing multiple varieties may ask FESCo to mediate.
| |
| | |
| It is also desirable in some cases to offer multiple varieties of tools. For instance, a future modularized release scheme may allow Apache 2.2 and 2.4 modules to coexist. We expect working groups will have needs for these multiples, and should develop a method to approve them where appropriate.
| |
| | |
| It may also be helpful in some cases to have the same piece of software available in multiple package formats. For example, both an RPM and a Docker version of Apache may be desirable.
| |
| It is not yet clear how to present this specific case without confusing end-users. However, some of the confusion may be handled through separate tools that only offer a specific version of the software. In this example, the Docker tools would not offer an RPM package.
| |
| | |
| === Repository definitions ===
| |
| | |
| {{admon/note | TBD | The concept is to have WGs and SIGs able to vary these according to their need or tolerance for different software. This is probably not to be solved through e.g. the fedora-release* packages.}}
| |
| | |
| == Extra Technical requirements Fedora Workstation ==
| |
| | |
| These technical requirements only apply to the Fedora Workstation. Other editions or spins are free to adopt them if they wish, but they are not meant to be Fedora wide.
| |
| | |
| === Definition of Desktop application ===
| |
| | |
| A GUI application is an application meant to run on a graphical desktop with a launcher in the GNOME Shell. Some desktop applications may not fit this description, such as a desktop-centric command line tool, but they should follow the generic third party applications rule for the moment.
| |
| | |
| === Keywords, metadata ===
| |
| | |
| The Fedora Workstation Working Group will publish further guidelines for setting keywords and metadata, beyond the formal requirements of the Appstream and desktop file specifications. The goal of the metadata is to help AppStream compliant software managers, such as GNOME Software, properly inform Fedora users about the software they're installing. This feature helps users make decisions in accordance with their own values and goals, and those of Fedora. It also helps ensure users are aware of whom to contact with questions or support in case of problems.
| |
| | |
| === Appstream Data - Applies to Desktop Applications ===
| |
| | |
| All applications available must come with metadata conforming to the Freedesktop Appstream standard. Details can be found [http://www.freedesktop.org/software/appstream/docs/ here].
| |
| | |
| === Desktop file - Applies to Desktop Applications ===
| |
| | |
| All applications must ship with a .desktop file. This is the file that determines how the application is presented in the Fedora Desktop shell. The latest specification is found [http://standards.freedesktop.org/desktop-entry-spec/latest/ here].
| |
| | |
| = Guide for third Party developers =
| |
| | |
| This guide is for third party developers who want to make their software available in a Fedora edition.
| |
| | |
| == Principles ==
| |
| | |
| While the inclusion process is one of procurement, meaning the process isn't a total free for all, we want it to be as objective and transparent as possible. The requirements on third party software providers must be easy to understand and applied in a fair and balanced manner.
| |
| | |
| Before you submit an application, please review the technical requirements for third party applications, libraries, and tools for Fedora. Also read any specific extra requirements for the Fedora edition you are targeting.
| |
| | |
| The submission process is edition-based. Acceptance into Fedora Workstation, for instance, does not guarantee your software will be as easily available in another Fedora Edition or in a Fedora Spin. It is up to each working group or special interest groups how to make available any software in their system.
| |
| | |
| == Submitting the application for consideration ==
| |
| | |
| Once your third party application conforms with the rules for inclusion, you can submit it for consideration by filing a ticket in the [https://redhat.bugzilla.com/bugzilla Fedora Bugzilla]. The component is called fedora-third-party-applications.
| |
| | |
| {{admon/note | TBD | Once such a component exists, the direct bug form/template will be linked above.}}
| |
| | |
| The relevant Fedora Working Group will then review your submission as quickly as possible.
| |
| | |
| == Maintaining your repository ==
| |
| | |
| You should notify the Fedora project as soon as possible if at any point you decide to stop maintaining your repository.
| |
| | |
| If the contents of your repository change, either in terms of licensing or the software offered, please notify Fedora immediately so that we can review the changes. Fedora may define and provide an agreement in order for third party software providers to be listed.
| |
| | |
| {{admon/note | Automation needed | jboyer: Need automation here, perhaps leveraging [https://github.com/fedora-infra/anitya anitya]?}}
| |
| | |
| The Fedora Project will also establish review procedures to ensure users are not provided dead or deprecated repositories.
| |
| | |
| {{admon/note | Clarification | Will this be done by FESCo, by the WGs and SIGs which select repos for their edition or spin, or by someone else? --[[User:Mattdm|Mattdm]] ([[User talk:Mattdm|talk]]) 17:42, 16 June 2016 (UTC) }}
| |
