#34 3rd party repo policy — alternative approach
Merged a year ago by zbyszek. Opened 2 years ago by zbyszek.
fesco/ zbyszek/fesco-docs third-party-policy  into  master

@@ -1,109 +1,83 @@ 

- = Third Party Repository Policy

+ = Third-Party Repository Policy

  

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

+ A third-party repository is any software repository that the Fedora Project does not officially maintain, including link:https://copr.fedorainfracloud.org/[Copr repositories], as well as repositories that are hosted outside of the Fedora Project.

  

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

+ This policy sets out the conditions under which Fedora editions and spins can include repository definitions that make the contents from those third party repositories available to users.

+ It applies to **repository definitions integrated with the usual package installation mechanisms** like `dnf` or GNOME Software. Unless such integration exists, this policy does **not** cover the packaging of:

+ * Language-specific tools (`pip`, `maven`, `cargo`, `go`, …).

+ * Tools that primarily exist to access external software packaging ecosystems (`snap`, `apt`, `pacman`, …).

+ * Tools that provide images of other systems (`docker`, `podman`, `machinectl`, …).

+ These tools can use third-party repositories without the restrictions described below.

  

- == Background & goals

+ This policy is intended to ensure quality and legal protections for the most critical and visible software mechanisms used by Fedora, while allowing special-purpose software management tools to function as expected. The policy also aims to ensure that software provided under its terms is clearly labeled, so users are fully informed about the origin of the software they are installing.

  

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

+ Software from third-party repositories cannot be used when creating Fedora images.

  

- This policy is motivated by:

+ == Third-party repository distribution

  

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

+ Third-party repositories should be distributed in descriptively named rpm packages.

+ Each third-party repository should be defined once through a separate (binary) package.

  

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

+ Traditionally, definitions for multiple repositories were combined into one package (for example, Fedora Workstation edition installs a package called `fedora-workstation-repositories`), but this is discouraged and should not be done in new cases.

  

- == Third party repository distribution

+ Repositories can be configured with either `enabled_metadata=0` or `enabled_metadata=1` (or equivalent),

+ at the discretion of the relevant working group or SIG.

  

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

+ If they fulfill the requirements set out in this policy,

+ a Fedora edition or spin install media can include third party repository definitions.

  

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

+ The third-party nature of the repository must be apparent to the user when they enable it,

+ as should the non-free status of its content, if such.

+ To ensure this, repository files must initially include the `enabled=0` (or equivalent) setting,

+ and the user must explicitly enable third-party repositories to install from them.

+ FESCo may grant an exception to waive this requirement.

  

- An edition or spin is free to include the third party repository definitions of one of the other editions if preferred.

+ Reuse of repository definitions among editions or spins is encouraged.

  

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

+ 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,

+ which produces a traceable history for each decision (for example, a ticket or other record).

  

- Additionally, repositories that are included in an edition or spin's third-party repository list must conform to the following requirements:

+ Additionally, repositories 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.

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

+ * Just as with any software hosted by Fedora, third party repositories must not contain material that poses an undue legal risk for the Fedora Project or its sponsors. This risk 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.

+ * Changes made by one Edition or spin should not impact other Fedora editions or spins.

+ * Working groups and SIGs should maintain oversight over the software that is made available through third-party repositories, to prevent unvetted software being made available to Fedora users. As part of this, third-party repositories should allow easy auditing by Fedora Legal. This requirement implies that third-party repositories should limit themselves to a small number of packages, or that measures should be put in place to define which packages are made available from a particular repository by default.

  

- 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 labeling and metadata

  

- === Software labelling and metadata

+ Third-party and non-free software should be identifiable to users through software management tools before installation.

+ In general, this requirement applies to the primary software management tools used in a given edition or spin.

+ For Fedora Workstation, this is GNOME Software, the primary software installer for the desktop.

  

- 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 software requirements

  

- == Third party software requirements

- 

- The software that is included in each third-party repository must conform to the following requirements.

+ Software included in each third-party repository must conform to the following requirements.

  

  === Software packaged as RPMs

  

- Requirements for software packaged using RPM:

+ Requirements for software packaged as RPMs:

  

- * 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 replace packages provided by official Fedora repositories, nor should the break dependencies between those packages.

+ * Applications that ship as RPMs should conform with link:https://docs.fedoraproject.org/en-US/packaging-guidelines/[Fedora's RPM guidelines]. However, while this is the best practice, it is not a hard requirement. (This more relaxed approach to RPM packaging allows the inclusion of software for which it is difficult to conform to Fedora's packaging guidelines.)

+ * Software must be included in an RPM repository as described in the link:https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/package-management/DNF/[Fedora System Administrators Guide].

+ * RPM packages in a third-party repository must not replace packages provided by official Fedora repositories, nor break dependencies between those packages.

  

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

- 

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

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

+ * Applications in other packaging formats should conform with guidelines and best practices appropriate for those formats.

  

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

- 

- === Duplicates

- 

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

- 

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

- 

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

- 

- 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

+ Third-party repositories can supplement official Fedora software.

+ In limited cases, they can be used to replace software included in the official Fedora repositories. Such situations require FESCo approval.

  

  == 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:

+ Those responsible for a repository 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

+ * repository maintenance ends or will end in the future

+ * the contents of the repository changes, either in terms of the software included or its licensing

  

- Fedora may also define agreements with third-party maintainers.

+ Fedora working groups or FESCo may also define agreements with third-party maintainers.

This builds on https://pagure.io/fesco/fesco-docs/pull-request/32, but tries to actually update the policy
so that things that are currently done in the project are not in violation of the policy.

First big change is to say that the policy only applies to 3rd party repos which integrate with normal package installation mechanisms, and anything like pip/cargo/snap etc. is excluded. I think this is enough to clear up all confusion where pip is in violation of the policy.

Second change is to say that repo definitions should be in separate (binary) packages. Previous policy stated that repo definitions should be shared between variants, but with all repositories jumbled into one package this is not realistic. Existing definitions are grandfathered in.

Third change is to say that FESCo may allow the 3rd party repo to be enabled by default. Currently fedora-cisco-openh264 is enabled by default.

Fourth change is to cut out a lot of about motivations and goals. I think a brief intro about goals is OK, but a policy text should not contain links to old blogs and other distractions.

The rules that the 3rd party repo should have a small scope so it is auditable remains unchanged. I believe that in the light of the first change this now actually makes much more sense.

Fifth change is to remove the recursive rules for software installation software included in 3rd party repos. On the one hand, such software is covered by the general rules already included in the policy. On the other hand, there a lot of specifics that are very complicated and the text that was in place wasn't nearly enough to properly regulate that. On the third hand, that text also made unrealistic requirements like "GNOME Software should be able to track and remove games installed using Steam." So if we ever want to include a 3rd party repo with an installer for arbitrary software that would integerate with normal package installation mechanisms, we should discuss that separately and update to policy to properly handle such cases.

Sixth change is to apply some minor grammar fixes.

I'm making this a separate PR because it goes in significantly different direction than @aday's work.

RPM packages must not require or recommend packages containing a .desktop file,

This rule confuses me. So an RPM package from a third party repository cannot depend on another RPM package (from the third party repository and/or from Fedora) if that package contains a desktop file?

RPM packages in a third party repository must not replace packages provided by official Fedora repositories
Third party repositories [of software packaged using other formats]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.

So I can package an alternate version of Firefox as a flatpak, but not as an RPM package?

This does not make sense. As described, this means that if a third party wraps and integrates packages from Fedora and from its own repo and those packages have .desktop files, they can't be in there? Given that we have console and web applications that provide those files, this seems particularly painful.

I think it'd be simpler to say each replacement should require FESCo approval.

This would trigger almost all the time, since at least both Workstation WG and KDE SIG both ship such enablement out of the box. It's simpler to just say let FESCo be the judge here.

Why would this ever reasonably be a preference? That would break our self-reliance principle embedded in how we deliver the distribution.

RPM packages must not require or recommend packages containing a .desktop file,

This rule confuses me. So an RPM package from a third party repository cannot depend on another RPM package (from the third party repository and/or from Fedora) if that package contains a desktop file?

Indeed. The motivation was to avoid pulling a lot of deps from a 3rd party package. But this rule only makes sense only sometimes. The general packaging guideline of not including unnecessary dependencies is enough. I'll remove this.

RPM packages in a third party repository must not replace packages provided by official Fedora repositories
Third party repositories [of software packaged using other formats]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.

So I can package an alternate version of Firefox as a flatpak, but not as an RPM package?

Yes. The way I understand this rule is that it makes sense to provide a firefox flatpak because the application runs in a different environment in this case. But it doesn't make sense to provide a different firefox rpm, because that'd just replace the distro firefox and all interesting changes can instead be introduced in the distro packages.

I don't care too much about this, and I'm happy to drop it if you think so.

line 92 of fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc a day ago

I think it'd be simpler to say each replacement should require FESCo approval.

OK.

Why would this ever reasonably be a preference? That would break our self-reliance principle embedded in how we deliver the distribution.

That's a list of characteristics that might apply in some cases but not others. In this particular case, I'd say that if there's an upstream flatpak and an unrelated 3rd party flatpak, all other things equal, we might go for the upstream one.

This would trigger almost all the time, since at least both Workstation WG and KDE SIG both ship such enablement out of the box. It's simpler to just say let FESCo be the judge here.

This whole rule is unnecessary. The rules that say that a repo should be defined by a single package and that those definitions should be reused, but what one spin does should not affect others, together, means that the reasonable thing should happen without this rule. I'll remove it.

5 new commits added

  • Fixes after first round of reviews
  • Shorten the policy and adjust it to match current practice
  • 3rd party repos policy: respond to feedback
  • 3rd party repos policy: abstract the diverse repos clause
  • 3rd party repos policy: merge wiki material
2 years ago

Updated. Please see the last commit for the summary message.

@zbyszek Other than the two grammar issues, this LGTM.

1 new commit added

  • Two wording fixes suggested in review
a year ago

Updated with the suggested changes.

It covers repository definitions that integrate those third-party repositories definitions...

This seems rather complex and I fail to parse it.

allow the package to be enabled by default

allow the repository to be enabled by default.

1 new commit added

  • Two small fixes after review
a year ago

7 new commits added

  • Two small fixes after review
  • Two wording fixes suggested in review
  • Fixes after first round of reviews
  • Shorten the policy and adjust it to match current practice
  • 3rd party repos policy: respond to feedback
  • 3rd party repos policy: abstract the diverse repos clause
  • 3rd party repos policy: merge wiki material
a year ago

It covers repository definitions that integrate those third-party repositories definitions...

This seems rather complex and I fail to parse it.

Indeed. I changed that now to "It covers repository definitions which are integrated with the usual package installation mechanisms like dnf or gnome-software." Together with the following paragraph about what is not covered, this should be pretty clear.

allow the package to be enabled by default

Fixed.

First big change is to say that the policy only applies to 3rd party repos which integrate with normal package installation mechanisms, and anything like pip/cargo/snap etc. is excluded. I think this is enough to clear up all confusion where pip is in violation of the policy.

My original PR came out of the Workstation Working Groups desire to include a subset of Flathub as a third party repository. What are the operating procedures for Flatpak repos with this version of the policy?

"Coprs that are hosted on Fedora Infrastructure" reads oddly to me. Perhaps just say 'Coprs' ?

This breaks the current setup in fedora workstation. The current workflow is that metadata only is enabled so gnome-software can 'see' things, but if they are in a 3rd party repo it can ask the user if they really want to enable that repo before installing. Without the metadata it just won't see those applications.

This is a pretty big re-write. Perhaps we should get a lookover by the council and/or legal?

Should we include that 3rd party repos cannot be used as part of creating fedora images? or is that obvious? or for another policy?

This is a pretty big re-write. Perhaps we should get a lookover by the council and/or legal?

Sorry, didn't go deep enough down the links... they punted to us. Still would be nice to get a legal ack, but not sure from whom.

In reply to @aday's comment:
[I wrote this a few days ago, but apparently didn't submit. I came back to the ticket to find the text waiting in the edit window :( ]

My original PR came out of the Workstation Working Groups desire to include a subset of Flathub as a third party repository. What are the operating procedures for Flatpak repos with this version of the policy?

The first question is whether this is covered by the proposed policy? Yes, because flatpaks as supported by gnome-software, the usual package installation mechanism.

I don't see state which packages would be provided from flathub. You mentioned "a filtered view". Below I assume the proposal is to provide some select flatpaks with additional software, and not replace rpms.

There's a bunch of rules in "Key requirements for third-party repositories". I think the flatpaks would satisfy those rules. In this case, Workstation SIG would give the approval to satisfy "Third party repositories must be approved by an active Fedora working group or SIG, or by FESCo."

If Steam is installed as a flatpak, the proposed policy explicitly does not cover things installed using Steam, because using Steam is "clearly separate from installation of Fedora packages".

So I think the proposed policy gives a path to Workstation SIG approval with some clear requirements. Does this answer your question?

In reply to @kevin:

"Coprs that are hosted on Fedora Infrastructure" reads oddly to me. Perhaps just say 'Coprs' ?

I'll make that change.

This is a pretty big re-write. Perhaps we should get a lookover by the council and/or legal?

I think it's mostly describing current practice. The policy is different, but it doesn't change much. But sure, we can ask legal to take a look.

Should we include that 3rd party repos cannot be used as part of creating fedora images? or is that obvious? or for another policy?

I think it's obvious, but it should be mentioned. I'll add that too.

This breaks the current setup in fedora workstation. The current workflow is that metadata only is enabled so gnome-software can 'see' things, but if they are in a 3rd party repo it can ask the user if they really want to enable that repo before installing. Without the metadata it just won't see those applications.

Indeed. I'll adjust the text to say that enabled_metadata=1 is OK. (That is what I was saying above: the policy is being adjusted to conform to reality.)

1 new commit added

  • Say that 3rd party soft cannot be used in images and allow enabled_metadata=1
a year ago

This breaks the current setup in fedora workstation. The current workflow is that metadata only is enabled so gnome-software can 'see' things, but if they are in a 3rd party repo it can ask the user if they really want to enable that repo before installing. Without the metadata it just won't see those applications.

This aspect of the policy was changed by Council back in March. You can see the corresponding commit here: https://pagure.io/fesco/fesco-docs/c/45b77f2f73d8b32423947a5760765c561c3df3dc?branch=master

So, what is the actual behaviour: do we ask the question before enabling metadata as required by 45b77f2?

So, what is the actual behaviour: do we ask the question before enabling metadata as required by 45b77f2?

Workstation currently follows the old policy (3rd party repos not shipped on install media, and are provided with enabled_metadata=1). We plan on updating to the new behaviour (repos included in install media with enabled_metadata=0) - that's being tracked at https://pagure.io/fedora-workstation/issue/105 .

Ah ha. MIssed that change (was it announced anywhere?)

MIssed that change (was it announced anywhere?)

Not that I'm aware of. I'd assume that there will be some publicity once workstation starts using the new policy.

My original PR came out of the Workstation Working Groups desire to include a subset of Flathub as a third party repository. What are the operating procedures for Flatpak repos with this version of the policy?

The first question is whether this is covered by the proposed policy? Yes, because flatpaks as supported by gnome-software, the usual package installation mechanism.

I don't see state which packages would be provided from flathub. You mentioned "a filtered view". Below I assume the proposal is to provide some select flatpaks with additional software, and not replace rpms.

There's a bunch of rules in "Key requirements for third-party repositories". I think the flatpaks would satisfy those rules. In this case, Workstation SIG would give the approval to satisfy "Third party repositories must be approved by an active Fedora working group or SIG, or by FESCo."

If Steam is installed as a flatpak, the proposed policy explicitly does not cover things installed using Steam, because using Steam is "clearly separate from installation of Fedora packages".

So I think the proposed policy gives a path to Workstation SIG approval with some clear requirements. Does this answer your question?

It does answer my question - thanks. Although, I have to say that I don't find the policy to be very clear. One central issue is the scope of the policy:

  • It's not clear why the policy is limited to DNF and whatever gnome-software supports. Some explanation would possibly help.
  • It's not clear what it means for a software mechanism not to be covered by the policy (line 8). Can an edition ship third party repos for snap/pip/cargo/etc or not? It would be good if the policy could be explicit and just say.
  • The gnome-software criteria feels arbitrary and slippery. gnome-software supports a range of software types, through a plugin architecture. It does firmware, snaps, flatpak, packages, rpm-ostree, etc etc. Those software types change over time, so it's a shifting target. In the future, we could easily introduce other software management tools which aren't gnome-software, but which are intended to be part of the default experience.
  • What about other software instalation methods which aren't DNF and don't have gnome-software support, like Podman?

In general I think I'd prefer to see a straight list of the permitted package types for 3rd party repos, rather than the rule about gnome-software support.

If the feeling is that we should continue with this PR rather than my own, I can help with changes here if you'd like. However, if you do want to make significant changes to the policy, it's going to need more discussion and consultation with Fedora Council (something that I had hoped to avoid). And, if we go down that route, there are two further changes we should consider:

  1. Splitting up the policy elements and responsibilities more clearly. Political aspects around software freedom, or issues around legal liability, are really Council's responsibility.
  2. Create another policy which covers which repositories can be used as primary repos (ie. repos which are included in the install media and are enabled by default), since this is the logical counterpart to the 3rd party repos policy. This was actually covered in the 3rd party repos policy (see here), and I split it out in my own edits, with the intention of finding a new home for it.

I've created #36 as the tracker issue for this.

I've created #36 as the tracker issue for this.

Actually the tracker issue is https://pagure.io/fesco/issue/2416 .

1 new commit added

  • Fix wording in various places
a year ago

1 new commit added

  • Replace the text "offer software in other formats in the future"
a year ago

I pushed two commits:
- "Fix wording in various places" incorporates @dcantrell's patch (with some minor tweaks where the grammar got broken).
- "Replace the text "offer software in other formats in the future"" removes a paragraph that was talking about adjusting the policy for other formats. It wasn't useful: policy may always be adjusted in the future after all. And we already have those "other formats", e.g. flatpak, so the whole paragraph was confusing. I think this change is non-controversial, but ptal.

I talked with @aday today about his concerns raised above. I think we're mostly good, but he'll submit some adjustments to wording with the intent to make the intent clearer in various places.

If anyone wants to review/comment/adapt this, I suggest waiting for @aday's comments first.

Here's a small set of stylistic changes, generally just intended to make the policy clearer. I hope the plain diff is OK, and feel free to cherry pick.

3c3
< A third-party repository is any software repository that the Fedora Project does not officially maintain, including link:https://copr.fedorainfracloud.org/[Copr repositories], as well as repositories that hosted outside of the Fedora Project.
---
> A third-party repository is any software repository that the Fedora Project does not officially maintain, including link:https://copr.fedorainfracloud.org/[Copr repositories], as well as repositories that are hosted outside of the Fedora Project.
6c6
< It covers **repository definitions integrated with the usual package installation mechanisms** like `dnf` or `gnome-software`.
---
> It applies to **repository definitions integrated with the primary package installation mechanisms** like `dnf` or `gnome-software`. Unless this rule applies, this policy does **not** cover the packaging of:
8c8,10
< This policy does not cover the packaging of tools that provide access to third-party software that is separate from the installation of Fedora packages. Language-specific tools (`pip`, `maven`, `cargo`, `go`, …), systems that implement access to third-party packaged software (`steam`, `snap`, `apt`, `pacman`, `appstream`, `flatpak`, `dnf` invoked with package URLs, …), and tools that provide images of other systems (`docker`, `podman`, `machinectl`, …) are **not covered** by this document.
---
> * Language-specific tools (`pip`, `maven`, `cargo`, `go`, …).
> * Systems that implement access to third-party packaged software (`steam`, `snap`, `apt`, `pacman`, `appstream`, `flatpak`, `dnf` invoked with package URLs, …).
> * Tools that provide images of other systems (`docker`, `podman`, `machinectl`, …).
10,12c12,14
< The policy aims to make a wide range of software available to Fedora users similarly to native packages,
< while ensuring that that software is clearly labeled,
< so users are fully informed about the origin of the software that they are installing.
---
> Typically, these tools and systems can use third party repositories without the restrictions described in this document.
> 
> This policy scope is intended to ensure quality and legal protections for the most critical and visible software mechanisms used by Fedora, while allowing special-purpose software management tools to function as expected. The policy also aims to ensure that software provided under its terms is clearly labeled, so users are fully informed about the origin of the software that they are installing.
21,23c23
< Traditionally, definitions for multiple repositories were sometimes
< combined into one package, but this is discouraged and should not be done in new cases
< (as an example, Fedora Workstation edition installs a package called `fedora-workstation-repositories`).
---
> Traditionally, definitions for multiple repositories were combined into one package (for example, Fedora Workstation edition installs a package called `fedora-workstation-repositories`), but this is discouraged and should not be done in new cases.
25c25
< If they fulfill the requirements set out in this policy, the Fedora edition or spin install media can include third party repository definitions.
---
> If they fulfill the requirements set out in this policy, an Fedora edition or spin install media can include third party repository definitions.
29,31d28
< Repositories may have the `enabled_metadata=1` (or equivalent) setting,
< so users can view the contents of the repository without enabling them explicitly.
< 
35a33,35
> Repositories can be configured with either `enabled_metadata=0` or `enabled_metadata=1` (or equivalent),
> at the discretion of the relevant working group or SIG.
> 
83d82
< 

Having gone through the policy again, two observations:

First, I still find the gnome-software criteria a bit problematic. For one, gnome-software integrates with fwupd, which uses the Linux Vendor Firmware Service, which I think would fall down on the requirement that: "third-party repositories should limit themselves to a small number of packages, or that measures should be put in place to define which packages are made available from a particular repository by default". I think we want to be able to enable firmware updates by default!

Second, the list of types of software that aren't covered by the policy includes "systems that implement access to third-party packaged software". It sounds like it's saying that the third party repo policy doesn't apply to tools that use third party repos, which is obviously contradictory. I'm not sure that this bit is actually necessary - if we say that language-specific tools and tools that provide images are out of scope, that seems sufficient?

First, I still find the gnome-software criteria a bit problematic. For one, gnome-software integrates with fwupd, which uses the Linux Vendor Firmware Service, which I think would fall down on the requirement that: "third-party repositories should limit themselves to a small number of packages, or that measures should be put in place to define which packages are made available from a particular repository by default". I think we want to be able to enable firmware updates by default!

Indeed it does! To satisfy this policy, those firmware updates need to either be explicitly enabled or we must approve them to be enabled automatically. It is possible that such approval has already happened when this was initially introduced.

Second, the list of types of software that aren't covered by the policy includes "systems that implement access to third-party packaged software". It sounds like it's saying that the third party repo policy doesn't apply to tools that use third party repos, which is obviously contradictory. I'm not sure that this bit is actually necessary - if we say that language-specific tools and tools that provide images are out of scope, that seems sufficient?

I think tools like steam do not qualify as either language-specific tools and tools that provide images, so we need a separate category for those. But you are right that this wording is unfortunate. I'll try revise it.

2 new commits added

  • Reword the scope definition again and reorder some sentences for clarity
  • A small set of stylistic changes, generally just intended to make the policy clearer
a year ago

Updated again. I think this is incrementally better than the previous versions, but please review again.

First, I still find the gnome-software criteria a bit problematic. For one, gnome-software integrates with fwupd, which uses the Linux Vendor Firmware Service ...

Indeed it does! To satisfy this policy, those firmware updates need to either be explicitly enabled or we must approve them to be enabled automatically. It is possible that such approval has already happened when this was initially introduced.

Second, the list of types of software that aren't covered by the policy includes "systems that implement access to third-party packaged software". It sounds like it's saying that the third party repo policy doesn't apply to tools that use third party repos ...

I think tools like steam do not qualify as either language-specific tools and tools that provide images, so we need a separate category for those.

Isn't the steam itself provided by a 3rd party rpm repo? Is the policy expected to act recursively?

But you are right that this wording is unfortunate. I'll try revise it.

Two potential alternatives to consider:

  1. State that the policy only applies to tools and repos that are pre-installed. That would cover dnf and flatpak, but would exclude the likes of apt, pacman, steam and snap.
  2. Just say that the policy only applies to dnf, flatpak and maybe snap.

Both of these probably are closer to the original intent of the policy (historically people have mostly seemed to care about proprietary desktop apps popping up in a way that's assisted by Fedora). They both have the disadvantage that they are somewhat unfair, in that they aren't treating all software management tools equally, and are putting our default tools at an disadvantage, but maybe that was the case all along.

Updated again. I think this is incrementally better than the previous versions, but please review again.

Thanks, it looks good from a style perspective. The only thing I'd do is move one sentence:

17a18,20
> If they fulfil the requirements set out in this policy,
> a Fedora edition or spin install media can include third party repository definitions.
> 
22,24d24
< 
< If they fulfill the requirements set out in this policy,
< a Fedora edition or spin install media can include third party repository definitions.

Thanks, it looks good from a style perspective. The only thing I'd do is move one sentence:

Done.

  1. State that the policy only applies to tools and repos that are pre-installed. That would cover dnf and flatpak, but would exclude the likes of apt, pacman, steam and snap.
  2. Just say that the policy only applies to dnf, flatpak and maybe snap.

I don't like this: if I install dnfdragora on my initially workstation machine, I think the rules should be the same as if I got it by installing from the KDE spin. Also, I don't want to include an explicit list of tools. We currently have quite a few, and the list is likely to change over time. (For example, what does Sugar, Pantheon, Deepin use?).

Isn't the steam itself provided by a 3rd party rpm repo?

Indeed. I removed Steam from the list.

2 new commits added

  • Remove steam from list of examples
  • Reorder two paragraphs in "Third-party repository distribution"
a year ago
  1. State that the policy only applies to tools and repos that are pre-installed. That would cover dnf and flatpak, but would exclude the likes of apt, pacman, steam and snap.
  2. Just say that the policy only applies to dnf, flatpak and maybe snap.

I don't like this: if I install dnfdragora on my initially workstation machine, I think the rules should be the same as if I got it by installing from the KDE spin.

I can see the logic in that.

Also, I don't want to include an explicit list of tools. We currently have quite a few, and the list is likely to change over time. (For example, what does Sugar, Pantheon, Deepin use?).

I was imagining that the explicit list would just be dnf, flatpak, snap - the back-ends we care about, rather than the front-ends. (I agree that a long, dynamic list wouldn't be practical.) Of course, for that to work, we'd need to be confident that that list really does cover everything that the Fedora project cares about...

RPM repository, we do technically have multiple tools that can consume RPM repositories...

I was imagining that the explicit list would just be dnf, flatpak, snap - the back-ends we care about, rather than the front-ends.

Sorry, I still think that a list is unnecessary and we'd have troubling keeping it up to date.

RPM repository

Let's not split hairs. If you have a clearly better wording, please suggest a diff. But if it's just a bit better, or covers a theoretical corner case, or whatever, please don't. I don't want this to go on for another year.

@zbyszek Seriously? We have DNF, PackageKit, Zypper, and in the past, YUM that work with Fedora package repositories. Calling it an "RPM repository" is way more accurate than calling it a "DNF repository".

@zbyszek I think I'm with @ngompa on this one. Best not to lock ourselves to DNF (who knows, DNF 5 could just decide to rebrand as YUM 5 for the hell of it.)

Okey, okey, I miscontrued what you wanted to change (pagure does not show context). I agree that "RPM repository" is better than "DNF repository". I'll push that one change shortly.

1 new commit added

  • Say "RPM repo" not "DNF repo"
a year ago

Looks great! :thumbsup:

No major objection to the current draft, based on the fact that it does everything the Workstation Working Group needs it to.

That said, I continue to struggle with this bit:

this policy does **not** cover the packaging of:
...
* Tools that provide access to other software packaging ecosystems (`snap`, `apt`, `pacman`, `appstream`, `flatpak`, `dnf` invoked with package URLs, …).

It isn't clear what it's trying to say. Any tool can provide access to other packaging ecosystems, can't it? If you read it literally it seems to imply that any package manager is exempt from the policy.

Perhaps this part means to refer to "tools which primarily exist to serve external ecosystems". However, in that case, the inclusion of appstream, flatpak and dnf in the examples don't make sense to me:

  • Isn't appstream just about the metadata?
  • flatpak is repo-agnostic by design, and Fedora has its own flatpaks, so I don't think you can claim that it is particularly focused on an external ecosystem
  • "dnf invoked with package URLs" - this policy is about which repos can be provided by Fedora, not what users can do with software management tools once we've given them to them

So, if I'm understanding the intent correctly, you could possible replace line 8 with:

* Tools that primarily exist to access external software packaging ecosystems (`snap`, `apt`, `pacman`, …).

So, if I'm understanding the intent correctly, you could possible replace line 8 with:

  • Tools that primarily exist to access external software packaging ecosystems (snap, apt, pacman, …).

OK, I can change to that. I don't think it matters much either way, but I'm happy to change if you find that better.

1 new commit added

  • Shorten the list of tools that access external packaging ecosystems
a year ago

I see this mangled in the HTML output, presumably by a missing newline.

1 new commit added

  • Change "Fedora" → "Fedora wgs or FESCo"
a year ago

rebased onto 2b9360c

a year ago

rebased onto 2b9360c 2 minutes ago

Oh, pagure, I didn't rebase anything. Don't make up stuff.

Approved in https://pagure.io/fesco/issue/2416#comment-677206.

Pull-Request has been merged by zbyszek

a year ago