#289 Improving the 3rd party repo experience
Closed: approved 4 years ago by bcotton. Opened 4 years ago by aday.

This ticket is being posted on behalf of the Fedora Workstation Working Group.

Two years ago, the Council approved the 3rd party software policy. This policy is being used by Fedora Workstation, but we have been unable to build a successful UI around it, largely due to the nature of the policy.

We would like to explore modifying the policy so that we can reliably integrate the 3rd party repos into the workstation experience.

How 3rd party repos work today

The 3rd party repos are a collection of repositories which can be enabled on Fedora Workstation. Each one:

  • Contains a single package
  • Is hosted externally
  • Is approved by the Workstation Working Group as well as Red Hat legal
  • Is not built or signed by Fedora
  • Can include proprietary software
  • Is disabled by default, but has metadata enabled

Today there are four 3rd party repositories, containing the following software: Google Chrome, Steam, the proprietary NVIDIA driver, and PyCharm.

The repos are shipped in a package called fedora-workstation-repos, which must be installed by the user. Theoretically this is supposed to be done as part of a step in initial setup (or through GNOME Software, as a backup).

Once installed, the content of each repo can be searched for and installed (though users must explicitly enable each repo as part of the install process).

Problems with the 3rd party repos

The main problem with the 3rd party repo policy is that it requires the 3rd party repos to be installed from a package. This makes it difficult (and in some cases impossible) to add a straightforward UI for enabling the 3rd party repos. This can be seen in specific issues like:

  • gnome-initial-setup has never had a functioning UI for installing the 3rd party repos, and we don't think that it's practical to add one. This is the main place that we want to expose the 3rd party opt-in to users.
  • Enabling the 3rd party repos can be slow due to having to refresh package metadata and so on.
  • The process of installing from one of the 3rd party repos isn't great for users, since they have to click through confirmation dialogs to enable each one. From a user perspective, the purpose of these dialogs isn't clear.
  • GNOME Software has to carry additional complexity to handle the 3rd party repositories, including special UI in the repository settings and the dialogs for enabling each repository.

Installing the 3rd party repos through a package is also a critical issue for Silverblue, since it requires package layering, which requires a restart to even start using the repositories.

A possible solution

The Workstation WG would love to discuss solutions to these practical problems, while continuing to retain the principles behind the original 3rd party repo policy. One potential solution that we have come up with would be to:

  1. Include fedora-workstation-repos in the workstation install media, with all its repos disabled and with metadata turned off.
  2. Add UI to gnome-initial-setup, to allow users to opt into the 3rd party repos. This would enable both the repositories and their metadata, and would be explicit about the proprietary nature of their content.

This arrangement would prevent users from being exposed to any sight of the 3rd party repo content until they have explicitly enabled them. It would also enable us to build a functional and reliable UI on top of the 3rd party repos.

We look forward to your feedback and discussing this further!


TL;DR: we want to install disabled proprietary repo files into /etc/yum.repos.d by default.

  • User experience is unchanged for users who don't enable the repos, except if you look into /etc/yum.repos.d you'll notice that the disabled repo files exist on disk, not doing anything.
  • For users who choose to enable the repos, the user experience will be a bit smoother since we don't have to install the fedora-workstation-repos package first anymore.

I think the proposal is a fine solution, so long as the "hey this is proprietary" is both clear and friendly.

I think the proposal is a fine solution, so long as the "hey this is proprietary" is both clear and friendly.

Thanks @bcotton . I'm sure we could run the proposed UI past the council, to get your input.

I'm sure we could run the proposed UI past the council, to get your input.

That would be great @aday.

With two +1 in the ticket and @psabata's +1 in today's meeting, this is approved.

Metadata Update from @bcotton:
- Issue close_status updated to: approved
- Issue status updated to: Closed (was: Open)

4 years ago

Thanks everyone! I assume that we'll need to update some of the documentation around this. I'll follow up separately.

Login to comment on this ticket.

Metadata