#32 Update 3rd party repo policy
Merged 2 years ago by zbyszek. Opened 2 years ago by aday.
fesco/ aday/fesco-docs master  into  master

@@ -1,39 +1,109 @@ 

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

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

  

- FESCo policy is that no third party repositories can be included in Fedora, other than according to the following exceptions.

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

  

- == Copr Repositories

+ == Background & goals

  

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

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

  

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

+ This policy is motivated by:

  

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

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

  

- == Other Repositories with only free (libre) software

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

  

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

+ == Third party repository distribution

  

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

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

  

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

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

  

- == Repositories with non-free (libre) software

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

  

- Repositories that contain non-free software may be offered to users under the following conditions:

+ == Key requirements for third-party repositories

  

- * Users must be presented with clear information about Fedora provided/Libre software vs Non-free/3rd party software.

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

  

- * Users must explicitly opt in to such repositories after the information is presented to them.

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

  

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

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

  

- Non-free software may not be presented to the user without explicit user enablement in any Fedora Edition or Spin

+ 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

+ 

+ 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

+ 

+ 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://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.

+ 

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

+ 

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

+ 

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

This PR is being submitted on behalf of the Workstation WG. There are two changes:

  1. Merge the workstation 3rd party repo policy into the FESCo one.
  2. Make the "diverse repos" clause more generic and therefore flexible.

Fedora Council has been asked to decide on these changes here.

Do I understand correctly that this is waiting for a council decision?

Do I understand correctly that this is waiting for a council decision?

Yes, that's correct.

Council has said that they'd prefer this to be decided by FESCo, so it looks like it can be dealt with here. The council ticket has some more background, if that's useful.

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.

That's a pretty high bar. I wonder if potential candidates for inclusion would be blocked by this.

I don't fully understand this sentence. How copr repos are different from the "external" ones?

What labelling means in this context? Name of packages, having metainfo.xml or?

I don't think this should be a hard requirement. It should probably say more about that package management tool will understand it.

I don't think this is realistic. DNF does not really scale for hundreds or thousands of repositories.

So we are not allowed to ship PIP because it does not implement any of things below? It is not very clear to me how those are relevant here.

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.

That's a pretty high bar. I wonder if potential candidates for inclusion would be blocked by this.

It should be noted that the existing policy was approved by the council, following a fairly lengthy discussion and review process. I wasn't part of that, so I can't speak to the motivation behind all the clauses, and maybe there's something that the council had in mind here that I'm not aware of.

With that in mind, I would suggest only changing the policy where it's really necessary, and trying to leave as much of the existing policy intact.

With regards to this specific clause, I guess that, if it were an issue in a particular case, we'd come calling to try and get the policy changed, and we might make council aware of that change.

I don't fully understand this sentence. How copr repos are different from the "external" ones?

I think it's just meant as a point of clarification that 3rd party repos can include coprs.

What labelling means in this context? Name of packages, having metainfo.xml or?

That's primarily labelling in GNOME Software, or equivalent. The idea was that it should be clear that something's proprietary before someone installs it.

I don't think this should be a hard requirement. It should probably say more about that package management tool will understand it.

The original line in the policy approved by council was:

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

I updated that with a newer link.

I think the general idea was "follow the best practice recommendations when creating repos". This seems fairly obvious so I wouldn't mind removing it.

Even if they have different name?

I assume that that was the intention when council passed the policy.

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.

That's a pretty high bar. I wonder if potential candidates for inclusion would be blocked by this.

I agree. This is completely unrealistic. But it's only a SHOULD requirement, so it should not be a hard blocker ...

So we are not allowed to ship PIP because it does not implement any of things below? It is not very clear to me how those are relevant here.

That's what council specified...

Overall I do not see a problem with this policy change. Though I have a concern with 3rd party repos delivering overrides for core system tools or libraries. I feel there needs to be some more explicit terms (maybe under "Adding duplicate packages") indicating what is and is not acceptable.

For example, let's say libjpeg-turbo is current in Fedora but there's a proposed patch for it that enables some new feature. It has not been accepted, but in a 3rd party repo some maintainer has taken that patch and rebuilt libjpeg-turbo. Now the 3rd party repo delivers a newer build of that package which may or may not introduce problems for other programs using that library.

3rd party repos, like Copr, make it easy for the above to happen and to some extent that will happen. But we should probably try to have some sort of overall policy in place favoring more stable things for Fedora. Perhaps 3rd party repos should carry a lower cost than the main Fedora repos? It might be sufficient to just document the goal in the policy and leave the WG with that in order to enforce inclusion or exclusion of a 3rd party repo. The main intent here should be to not surprise users.

I don't understand the requirements for PyPI (and the entire Software management tools section). PyPI is the package index, the tool that we include in Fedora is called pip. pip can install software from all various places on the internet (same as dnf/yum BTW).

The software they provide must conform to the legal requirements outlined above.

The tools themselves provide no software. They are tools that allow users to fetch and install software from the internet. Legal or illegal alike. The default "software repository" used via pip can contain anything. It is not realistic to verify the entire PyPI content for "legal requirements outlined above" (and it is likely not met anyway) and it is impossible to verify the entire internet content for "legal requirements outlined above" (but it is easy to prove it doesn't meet the criteria).

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.

We already try this very hard with pip. Regardless, if you try harder, you can nuke your system with sudo pip. However, it is easier to use sudo rm to do that.

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.

This is a "should", however I consider it totally unrealistic.

Where has this Software management tools section originated from?

Considering the requirements already apply for Fedora Workstation, does this mean we need to nuke pip from Workstation and if approved here, we nuke it from Fedora entirely?

I am looking at https://fedoraproject.org/w/index.php?title=Workstation%2FThird_party_software_policies&type=revision&diff=575241&oldid=511620

The rules about PyPI (and other similar things) have changed (possibly not intentionally) from (paraphrased):

Software from PyPI (etc.) must be legally OK and play nice with the RPM packaged content to be considered for inclusion.

(Not sure about the "inclusion" true meaning here: inclusion to what exactly, Fedora Workstation itself?)

To:

Software management tools must only provide content that is legally OK and plays nice with the RPM packaged content.

This is a fairly new (and extensive) edit/rewrite of the policy by @aday. I cannot find a place where this was discussed, so I don't know if this particular change wrt PyPI/pip was intentional.

@churchyard doesn't this equally apply to almost all language specific package managers (cargo, bundler, pip, go, etc.)? They all can install and overwrite files on the "host system" when run with root privileges ...

Technically they can. According to this proposed policy, they cannot. Which is why I consider it a bad idea (or an honest mistake when doing the rewrite).

Overall I do not see a problem with this policy change. Though I have a concern with 3rd party repos delivering overrides for core system tools or libraries. I feel there needs to be some more explicit terms (maybe under "Adding duplicate packages") indicating what is and is not acceptable.

Line 55 reads:

* RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories.

That sentence isn't the clearest, but I'd read it as saying that you can't replace packages? If we agree I can clarify it.

I can also add some clarification to the "replacements and duplicates" section, so that it's consistent with that line. The main issue there is line 88, which reads:

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.

Since that's in the duplicates section, I'd assume that it means that such packages must be parallel installable? We could state that explicitly.

For example, let's say libjpeg-turbo is current in Fedora but there's a proposed patch for it that enables some new feature. It has not been accepted, but in a 3rd party repo some maintainer has taken that patch and rebuilt libjpeg-turbo. Now the 3rd party repo delivers a newer build of that package which may or may not introduce problems for other programs using that library.

If the version of libjpeg-turbo in the 3rd party repo replaced the one in the official repos, my reading is that the situation you describe contravenes the policy.

Considering the requirements already apply for Fedora Workstation, does this mean we need to nuke pip from Workstation

No - the policy only covers 3rd party repositories (those that aren't hosted by Fedora but which we include in the install media, in a disabled state). The policy doesn't apply to Pip from the official repos.

and if approved here, we nuke it from Fedora entirely?

My understanding is that this policy already applies to all of Fedora; at least, that's the way it's written.

Considering the requirements already apply for Fedora Workstation, does this mean we need to nuke pip from Workstation

No - the policy only covers 3rd party repositories (those that aren't hosted by Fedora but which we include in the install media, in a disabled state). The policy doesn't apply to Pip from the official repos.

So, to clarify - this policy only applies to third-party yum repositories shipping RPM packages, not to other means if installing software? If so, could you add this clarification to the proposed text?

Considering the requirements already apply for Fedora Workstation, does this mean we need to nuke pip from Workstation

No - the policy only covers 3rd party repositories (those that aren't hosted by Fedora but which we include in the install media, in a disabled state). The policy doesn't apply to Pip from the official repos.

So, to clarify - this policy only applies to third-party yum repositories shipping RPM packages, not to other means if installing software? If so, could you add this clarification to the proposed text?

This is the 3rd party repo policy. By definition, it doesn't apply to the official repos. I'm not sure how to make that any clearer...

Maybe the software management tools section is causing confusing because it mischaracterises how such tools work, irrespective of how they are distributed. It would constitute a modification of the policy as approved by council, but we could take out any bits that are nonsensical. :smile:

Hmm, why are the third party repositories bundled into one rpm. Shouldn't there be one rpm per third-party repo?

I'd expect something like this:
"Third-party repositories must be configured through a clearly named rpm package.
For any third-party repository, there should be just one package to minimize the risk of install conflicts and duplication.
As an example, most Fedora installations contain fedora-cisco-openh264 which provides Openh264 codecs from cisco."

Working groups should ensure that the software included in any third party repository is reliable.

Maybe drop this whole part? As discussed in the ticket, this is infeasible for a SIG to do in many cases.

Working groups and SIGs should maintain close control over the software that is made available through third party repositories

This contradicts the Steam example used below. And more generally, this is going to be a blocker for any kind of general software store.
For example we could not offer snaps as an option. I think this is too constrictive. Instead, I think the user should be warned that they
are enabling a source of software that is under external management and while fedora did some vetting, in cannot take responsibility
for the external software, and that the this external software is governed by different rules.

Hmm, why are the third party repositories bundled into one rpm. Shouldn't there be one rpm per third-party repo?

Historically, 3rd party repo enablement was done by installing that one package . However, we plan on changing that - for F33 we want to include the 3rd party repos in the install media, in a disabled state.

The other reason is probably that keeping them in a single package is easier.

Shouldn't there be one rpm per third-party repo?

I don't know... should there? fedora-cisco-openh264 is a bit special, and isn't a 3rd party repo, which I think is why it's in a package of its own.

Maybe drop this whole part? As discussed in the ticket, this is infeasible for a SIG to do in many cases.

I'm not sure which parts of the ticket you're referring to here. I don't see why it's infeasible - a SIG or WG can generally predict if a repo will be reliable, depending on who maintains it.

Working groups and SIGs should maintain close control over the software that is made available through third party repositories

This contradicts the Steam example used below.

That's true. I'll try and find out what the original authors thought about Steam in relation to this clause.

And more generally, this is going to be a blocker for any kind of general software store.

Correct - this clause does prevent Flathub or the Snap Store being shipped as a 3rd party repos.

For example we could not offer snaps as an option. I think this is too constrictive. Instead, I think the user should be warned that they
are enabling a source of software that is under external management and while fedora did some vetting, in cannot take responsibility
for the external software, and that the this external software is governed by different rules.

My understanding is that this clause is primarily a legal requirement and that we can't circumvent legal liability through a user opt in.

Maybe drop this whole part? As discussed in the ticket, this is infeasible for a SIG to do in many cases.

I'm not sure which parts of the ticket you're referring to here. I don't see why it's infeasible - a SIG or WG can generally predict if a repo will be reliable, depending on who maintains it.

The text says "ensure that the software included in [the] repository is reliable". This is much more than ensuring the the "repo will be reliable". I'm not sure if we can even say this about packages in Fedora itself. Packages have bugs, and it could be argued that the software we provide is not entirely reliable. And making this kind of promise for third parties is even harder.

It would be reasonable to say that the SIG must verify that the third party repo has rules in place and that those rules provide some kind of reasonable promises.

Overall I do not see a problem with this policy change. Though I have a concern with 3rd party repos delivering overrides for core system tools or libraries. I feel there needs to be some more explicit terms (maybe under "Adding duplicate packages") indicating what is and is not acceptable.

Line 55 reads:
* RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories.

That sentence isn't the clearest, but I'd read it as saying that you can't replace packages? If we agree I can clarify it.

That's how I read it and yes, it could use some clarification.

I can also add some clarification to the "replacements and duplicates" section, so that it's consistent with that line. The main issue there is line 88, which reads:
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.

Since that's in the duplicates section, I'd assume that it means that such packages must be parallel installable? We could state that explicitly.

Agreed, I think it should be explicitly stated.

For example, let's say libjpeg-turbo is current in Fedora but there's a proposed patch for it that enables some new feature. It has not been accepted, but in a 3rd party repo some maintainer has taken that patch and rebuilt libjpeg-turbo. Now the 3rd party repo delivers a newer build of that package which may or may not introduce problems for other programs using that library.

If the version of libjpeg-turbo in the 3rd party repo replaced the one in the official repos, my reading is that the situation you describe contravenes the policy.

OK, we're on the same page then. Some rephrasing of the above points would be useful.

1 new commit added

  • 3rd party repos policy: respond to feedback
2 years ago

3 new commits added

  • 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

I've attempted to respond to the feedback here in this commit. The changes are intended to be clarifications rather than substantive policy changes, but I do think that they address most of the comments here.

Can I get another round of review on this?

Third party repositories can software which is itself a mechanism or system for installing further software packages.

This is probably missing some word(s).

When a software management tool is provided by a third party repositoriy, it must conform to the following requirements: ...

So the rules apply to 3rd party repositories only, but not for 1st party? E.g. we can package pip for Fedora, but we cannot provide an alternate version of pip from a third party repo?

Third party repositories can software which is itself a mechanism or system for installing further software packages.

This is probably missing some word(s).

Thanks, fixed.

When a software management tool is provided by a third party repositoriy, it must conform to the following requirements: ...

So the rules apply to 3rd party repositories only, but not for 1st party? E.g. we can package pip for Fedora, but we cannot provide an alternate version of pip from a third party repo?

Correct. That's my understanding of the logic of the original policy, and is what I've attempted to clarify in the text. (We could change it, but that would have to be an explicit policy change.)

3 new commits added

  • 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

Correct. That's my understanding of the logic of the original policy, and is what I've attempted to clarify in the text. (We could change it, but that would have to be an explicit policy change.)

If that's the case, then we should change that policy.

I suggest a weaker statement here, something along a generalization of ... if an alternative version of "pip" is provided from a third party repository, it must use the same repository / repositories for providing third-party packages as the "pip" package that's available from the official fedora repository.

Does that make sense, @churchyard ?

My understanding about the policy was that the rules apply to software included in Fedora via a 3rd party software management tool, not about the software management tools themselves.

A.k.a. my understanding of the intent is: if we decide to ship "black" via "pip install black" on the Python Classroom Lab, we need to make sure "black" follows the rules.

Current text suggest that If we decide to ship "pip" from a copr repository, we need to make sure all software on the internet follows the rules. Such rule is non-realistic and could be replaced with: "It is not permitted to ship software management tools from third party repositories." -- that is if that was indeed the intention, which I think wasn't.

Does that make sense, @churchyard ?

Not really. I don't understand why such rule is needed. Care to elaborate?

Basically, if this was the intent:

Such rule is non-realistic and could be replaced with: "It is not permitted to ship software management tools from third party repositories." -- that is if that was indeed the intention, which I think wasn't.

Care to elaborate?

Then the restriction to the same sources for software installation would be a weaker restriction that to not allow it at all.

But I can't find the section of the policy change that I referred to in the latest version, the diff is now kinda all over the place.

Current text suggest that If we decide to ship "pip" from a copr repository, we need to make sure all software on the internet follows the rules.

The policy would only apply to "pip" if you wanted to provide it under the 3rd party repos terms (ie. repo included by default but disabled, and has to be explicitly enabled by the user).

Is there something specific that this policy clause would prevent? As in, is there something that a Fedora edition is currently doing, or is planning to do, which would be blocked? If there's not, I wonder why this is an issue.

I suspect that the original policy was intended (again, I wasn't involved) to permit Steam to be included but keep the door somewhat shut to unknown third party portals, largely from a liability perspective.

The policy would only apply to "pip" if you wanted to provide it under the 3rd party repos terms (ie. repo included by default but disabled, and has to be explicitly enabled by the user).

And why does such pip harder rules than pip shipped from Fedora repos?

Is there something specific that this policy clause would prevent? As in, is there something that a Fedora edition is currently doing, or is planning to do, which would be blocked?

Shipping a newer version fo pip from a third party repo. I can imagine this to be something we should be able to do, but no, there are no current plans to do it at this moment AFAIK.

I wonder why this is an issue.

It is an issue to me, because the rule makes no sense to me. Maybe I misinterpret it, but as I understand it, it's very weird rule.

The policy would only apply to "pip" if you wanted to provide it under the 3rd party repos terms (ie. repo included by default but disabled, and has to be explicitly enabled by the user).

And why does such pip harder rules than pip shipped from Fedora repos?

3rd party repos aren't packaged by Fedora and in some respects there are fewer restrictions (the main one being that 3rd party repos can include proprietary software). Fedora also has less control over the software in 3rd party repos, because we don't host it ourselves.

I assume that the reason the 3rd party repo policy is more restrictive in some respects is to:

a) keep the use of 3rd party repos relatively limited in the grand scheme of things (so Fedora-hosted software continues to be the norm)
b) prevent increased legal risk, particularly with repos we don't directly control, and maybe isn't as monitored as closely
c) limit the amount of proprietary software being distributed

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

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

Update: wrong ticket, please disregard.

Pull-Request has been merged by zbyszek

2 years ago

Arrrgh, I merged the wrong PR. I'll revert this, and merge #34 instead.