Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2010353 - optional software repos can't be disabled
Summary: optional software repos can't be disabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-software
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Milan Crha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F36FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-10-04 13:52 UTC by Kamil Páral
Modified: 2022-01-29 06:39 UTC (History)
8 users (show)

Fixed In Version: gnome-software-41.0-5.fc35 gnome-software-41.3-2.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-29 06:39:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
RPM repos in gnome-software (deleted)
2021-10-04 13:52 UTC, Kamil Páral
no flags Details
F34 repos in GS (deleted)
2021-10-05 11:15 UTC, Kamil Páral
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME gnome-software issues 1479 0 None None None 2021-10-06 09:39:16 UTC

Description Kamil Páral 2021-10-04 13:52:21 UTC
Created attachment 1829049 [details]
RPM repos in gnome-software

Description of problem:
In GNOME Software -> Software Repositories, some repos are force-enabled and their toggles are greyed out, i.e. they can't be disabled (note, there's a bug 2005343 currently presenting a hidden temporary workaround). Those repos are:
fedora
fedora-modular
fedora-cisco-openh264
updates
updates-testing
(I'm omitting fwupd and fedora flatpak repos).

The repos which can be freely toggled on and off are:
updates-modular
updates-testing-modular

This split doesn't seem to make much sense, i.e. "updates" and "updates-modular" should be handled the same way, in my opinion.

But the biggest problem is with "updates-testing". It's forced enabled, and you can't disable it. Of course, with F35 Final we'll ship it disabled by default, so you might say this is not a problem. It is. If you simulate this scenario (by manually disabling this repo outside of gnome-software), gnome-software shows it as disabled, but if use the toggle to enable it, again you can no longer disable it. So users who will just try to enable it will end up with a system where they can't disable it again.


Version-Release number of selected component (if applicable):
gnome-software-41.0-1.fc35.x86_64

How reproducible:
100%

Steps to Reproduce:
1. open gnome-software -> Software Repositories
2. try to disable "Fedora 35 - Test Updates", you can't
3. simulate an F35 Final system by running "sudo dnf config-manager --set-disabled updates-testing"
4. reboot
5. open gnome-software, check that "Test Updates" are disabled
6. enable "Test Updates"
7. try to disable "Test Updates" again, you can't

Comment 1 Kamil Páral 2021-10-04 13:55:30 UTC
Proposing as a FinalBlocker. Configuring repositories is a basic functionality of a package manager, and the inability to disable updates-testing is a bug which can break users' systems.

"All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test. "
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality

Comment 2 Milan Crha 2021-10-04 14:14:11 UTC
Thanks for a bug report. The reason is that the updates-testing is defined as an official-repository, which can be enabled, but cannot be disabled, The list [1] should be revisited, it seems. It currently lists:

official-repos = [ 'anaconda', 'fedora', 'fedora-debuginfo', 'fedora-source', 'koji-override-0', 'koji-override-1', 'rawhide', 'rawhide-debuginfo', 'rawhide-source', 'updates', 'updates-debuginfo', 'updates-source', 'updates-testing', 'updates-testing-debuginfo', 'updates-testing-source', 'fedora-modular', 'fedora-modular-debuginfo', 'fedora-modular-source', 'rawhide-modular', 'rawhide-modular-debuginfo', 'rawhide-modular-source', 'fedora-cisco-openh264', 'fedora-cisco-openh264-debuginfo' ]

It's true the official-repos key meaning changed in the 41.x release.

I'm not the decision maker here, thus I added Allan for his opinion.

[1] https://src.fedoraproject.org/rpms/gnome-software/blob/rawhide/f/gnome-software.spec#_134

Comment 3 Allan Day 2021-10-04 14:49:23 UTC
The intention behind the design was to prevent users from disabling essential repos which are required to receive system updates. The intended behaviour was that such repositories should be enabled and insensitive by default.

From this perspective, the list of official repos probably isn't correct, though I don't know what all those repos do.

I also agree that it is surprising behaviour for a repository to be sensitive and disabled, only to become insensitive when enabled.

I know that elsewhere we've started using the official-repos key to identify software that's provided by the distribution, and I was nervous about doing that because it conflates two different definitions of official. I hope it doesn't become an issue for us...

Comment 4 Milan Crha 2021-10-04 15:16:46 UTC
> I also agree that it is surprising behaviour for a repository to be sensitive and disabled, only to become insensitive when enabled.

That was to be able to enable an "accidentally" disable repo from other that the GNOME Software, like from a command line, by editing the repo files and such.

> From this perspective, the list of official repos probably isn't correct, though I don't know what all those repos do.

I cannot speak about the list myself too, I do not know the intention why they all are there.

It looks like the list of the official repos in Fedora, to server the meaning for the repository dialog in the Software, is:

   'anaconda', 'fedora', 'updates', 'fedora-cisco-openh264'

but it can have side effect on the details page, when an app comes for example from a "rawhide" repo or "fedora-modular" repo (then those apps will be shown as provided by a third-party, if I'm not mistaken). Then you might be right with the "I hope it doesn't become an issue for us...".

Comment 5 Adam Williamson 2021-10-04 15:40:08 UTC
I think we may need to draw a distinction between "official" repos and "core" or "required" repos, as we seem to have two different purposes here: deciding whether a package is from an "official" repo or not for display purposes, and deciding whether to allow for disabling a repo. updates-testing is indeed an 'official' repo, but one it is reasonable to want to disable, so it is not "required" in that sense.

The obvious "required" repos are 'fedora' and 'updates'. Also for Rawhide installations, 'rawhide'. Maybe also 'fedora-modular' and 'fedora-updates-modular'; I'm not sure if we "support" disabling those repos entirely if you don't want to use modules, or if we do kinda expect them to always be available.

IIRC, I think 'anaconda' is a sort of special case; it represents packages which were installed at deployment time, or possibly packages which were 'installed' from something like a live image. Anyway, it's not actually a remote repository defined in fedora-repos.

Milan, I'm not sure what the meaning is behind the two different lists you provided in comments 2 and 4?

Comment 6 Allan Day 2021-10-04 15:53:23 UTC
Upstream issue: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1479

Comment 7 Milan Crha 2021-10-04 15:57:22 UTC
> Milan, I'm not sure what the meaning is behind the two different lists you provided in comments 2 and 4?

The comment #2 contains the current list, when installing the gnome-software. The comment #4 contains my proposal for the "required-repos".

You summarized it very well, there will be needed two keys (or two notations), one for the "official-repos" and the other one for the "required-repos".

Comment 8 Zbigniew Jędrzejewski-Szmek 2021-10-05 08:40:58 UTC
> Maybe also 'fedora-modular' and 'fedora-updates-modular'; I'm not sure if we "support" disabling those repos entirely if you don't want to use modules, or if we do kinda expect them to always be available.

Yes, completely removing those repos from the system is completely supported.
This went through a FESCo vote in https://pagure.io/fesco/issue/2114.

Since they can be deselected through 'dnf remove' and 'dnf config-manager', I would expect
that they can be deselected in gnome-software too.

Comment 9 Zbigniew Jędrzejewski-Szmek 2021-10-05 08:41:59 UTC
> 'fedora-cisco-openh264'

This one too: users should be able to opt-out.

Comment 10 Kamil Páral 2021-10-05 09:44:55 UTC
> But the biggest problem is with "updates-testing". It's forced enabled, and you can't disable it.

Please note, this problem also applies to 'fedora-testing' flatpak repo. Disabled by default, but when enabled, can't be disabled again.

Comment 11 František Zatloukal 2021-10-05 10:07:27 UTC
The decision to classify this bug as an AcceptedBlocker was made:

"Being able to enable updates-testing but not disable it again both looks bad and can potentially cause problems, so we agree that this violates "All applications that can be launched...after a default installation of Fedora Workstation on the x86_64 architecture must...withstand a basic functionality test."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2021-10-04/f35-blocker-review.2021-10-04-16.02.log.html

Comment 12 Milan Crha 2021-10-05 10:36:20 UTC
Okay, there are two options I can see for this, before a correct change is made upstream:
1) change the list of the `official-repos` in the .spec file - disadvantage: software from the removed repos will be presented as unsafe, provided by a third party
2) add local patch for the gnome-software to temporarily allow disable of any .source - disadvantage: minor, I'd say, users can disable any repo, including the "required" repos.

Which way to go? Or feel free to suggest the third+ option.

Comment 13 Allan Day 2021-10-05 11:09:20 UTC
(In reply to Milan Crha from comment #12)
> Okay, there are two options I can see for this, before a correct change is
> made upstream:
> 1) change the list of the `official-repos` in the .spec file - disadvantage:
> software from the removed repos will be presented as unsafe, provided by a
> third party
> 2) add local patch for the gnome-software to temporarily allow disable of
> any .source - disadvantage: minor, I'd say, users can disable any repo,
> including the "required" repos.
> 
> Which way to go? Or feel free to suggest the third+ option.

1 clearly wouldn't be acceptable. 2 would essentially be reinstating the behaviour we had in F34, so probably is acceptable in the short term.

The 3rd option would be to introduce a new "essential" or "required" key, but I suspect that's more F35 territory.

Comment 14 Kamil Páral 2021-10-05 11:15:26 UTC
Created attachment 1829361 [details]
F34 repos in GS

(In reply to Allan Day from comment #13)
> 2 would essentially be reinstating the
> behaviour we had in F34, so probably is acceptable in the short term.

Actually, on F34 (and F33), the main fedora repos ('fedora' and 'updates') weren't displayed at all, so you couldn't disable them. See the screenshot (note: the 'fedora' and 'fedora-testing' repos listed are flatpak repos, not rpm ones).

Comment 15 Milan Crha 2021-10-05 11:53:12 UTC
All these things are new in f35. The f34/f33 has its own issues, which were not fixed there.

> The 3rd option would be to introduce a new "essential" or "required" key

Yeah, that's the upstream proposed fix about. I can eventually backport it (once it's completed and accepted by the upstream, which may happen possibly today or this week), for a disadvantage of not having translated the new key's summary and description in the GSettings, which might not be a problem, from my point of view.

Comment 16 Kamil Páral 2021-10-06 07:50:14 UTC
Milan, I just found out that if I install flathub repo using:
$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
then I can't disable that repo in gnome-software either. But I don't see it mentioned in the 'official-repos' key. Is this related, or a different bug?

Comment 17 Milan Crha 2021-10-06 08:14:04 UTC
(In reply to Kamil Páral from comment #16)
> Milan, I just found out that if I install flathub repo using:
> $ flatpak remote-add --if-not-exists flathub
> https://flathub.org/repo/flathub.flatpakrepo
> then I can't disable that repo in gnome-software either. But I don't see it
> mentioned in the 'official-repos' key. Is this related, or a different bug?

It's by design. The system-installed flatpaks cannot be disabled, it's up to the machine maintainer, not a random user, to disable such remotes.

Comment 18 Kamil Páral 2021-10-06 09:03:15 UTC
> It's by design. The system-installed flatpaks cannot be disabled, it's up to the machine maintainer, not a random user, to disable such remotes.

I'm a little confused. Because of bug 2011176 I had to test with F34. And on F34, I can add flathub repo through gnome-software (by opening the flatpakrepo file from the browser), it installs the repo as a *system* one, and I can later remove it. I'm in the wheel group, so gnome-software asks me to authenticate, which I do.

What is different in F35? Especially since we just agreed that the user should be able to disable updates-testing (when having sufficient admin privileges, of course), which is a system-wide dnf repo, why shouldn't he also be able to disable a system-wide flatpak repo (again, with admin privileges)?

(If you feel this is a distinct topic from the bug discussed here and we should have a separate bug report for it, tell me, and I can move this discussion there).

Comment 19 Milan Crha 2021-10-06 09:39:16 UTC
> What is different in F35?

Everything, I'd say. There had been done a major redesign all over the Software for the 41.0.

I made a mistake, the disable should be possible, but the remove not. I updated the upstream fix for [1] accordingly.

[1] https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1479

Comment 20 Kamil Páral 2021-10-06 10:11:06 UTC
> I made a mistake, the disable should be possible, but the remove not. I updated the upstream fix for [1] accordingly.

Great, thanks. If I understand the new system correctly, I'm still mildly concerned that users will be able to add new flatpak remotes in a GUI-only way, but they won't be able to remove them afterwards (GUI-only), only disable them. So the unwanted repos will just pile up in there, if they don't know how to operate the cmdline. That is different from RPM repos, where you can't add them in a GUI-only way, and therefore it feels normal that the GUI doesn't allow you to remove them either. But that is a different topic, so let's not dilute this bug with it. Thanks for clarification.

Comment 21 Milan Crha 2021-10-08 05:29:42 UTC
I sat only [ 'fedora', 'updates' ] as the "required-repos" in the .spec file. If more/others are needed, just let me know.

Comment 22 Fedora Update System 2021-10-08 06:04:20 UTC
FEDORA-2021-979587cebf has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-979587cebf

Comment 23 Adam Williamson 2021-10-08 06:09:32 UTC
Milan: thanks a lot!

Comment 24 Lukas Ruzicka 2021-10-08 09:10:27 UTC
I can confirm that Gnome Software now only disables Fedora and Updates. Other repositories can be switched on and off deliberately. 
According to comment #23, I believe that this behaviour was approved and therefore I am setting this to VERIFIED.

Comment 25 Fedora Update System 2021-10-08 19:08:04 UTC
FEDORA-2021-979587cebf has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-979587cebf`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-979587cebf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 26 Fedora Update System 2021-10-11 07:38:52 UTC
FEDORA-2021-979587cebf has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-979587cebf

Comment 27 Kamil Páral 2021-10-11 10:32:48 UTC
Verified fixed with gnome-software-41.0-5.fc35.

Comment 28 Fedora Update System 2021-10-11 17:16:30 UTC
FEDORA-2021-979587cebf has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-979587cebf`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-979587cebf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 29 Fedora Update System 2021-10-11 22:28:49 UTC
FEDORA-2021-979587cebf has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 30 Kamil Páral 2022-01-25 12:13:12 UTC
Milan, this is broken again with gnome-software-41.3-1.fc35.x86_64. I can't disable the following rpm repos:
fedora
updates
updates-testing
fedora-cisco-openh264
fedora-modular

According to comment 21 only the first two should be forced enabled, and I should be able to disable the rest.

A similar problem affects flathub repos, but it's even worse. I can't disable ANY flatpak repos! Currently those are:

$ flatpak remotes --columns=name,options,url
Name           Options    URL
AppCenter      system     https://flatpak.elementary.io/repo
fedora         system,oci oci+https://registry.fedoraproject.org
fedora-testing system,oci oci+https://registry.fedoraproject.org#testing
flathub        system     https://dl.flathub.org/repo/
flathub-beta   system     https://dl.flathub.org/beta-repo/
gnome-nightly  system     https://nightly.gnome.org/repo/

I suppose that only 'fedora' repo should be potentially forced enabled, anything else I should be able to disable. Also the previous problem persists, where I can enable such a repo (if it is already disabled), but then I can't change it back to disabled.

Comment 31 Kamil Páral 2022-01-25 12:22:24 UTC
Tracking this against the F36FinalBlocker, so that we don't lose sight of it.

Comment 32 Milan Crha 2022-01-26 08:49:43 UTC
I see I dropped those extra patches accidentally when making 41.1 release. I'll return them back.

Comment 33 Milan Crha 2022-01-26 09:08:38 UTC
I forgot to mention, those patches are already part of the 42.x, which is in rawhide, thus also in the upcoming f36.

Comment 34 Kamil Páral 2022-01-26 09:22:25 UTC
(In reply to Milan Crha from comment #33)
> I forgot to mention, those patches are already part of the 42.x, which is in
> rawhide, thus also in the upcoming f36.

Good to know. I wanted to test Rawhide, but currently the Workstation Live ISO doesn't even boot :-/ Will try later.

Comment 35 Fedora Update System 2022-01-26 09:26:59 UTC
FEDORA-2022-7c4684e124 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7c4684e124

Comment 36 Kamil Páral 2022-01-26 11:10:19 UTC
(In reply to Fedora Update System from comment #35)
> FEDORA-2022-7c4684e124 has been submitted as an update to Fedora 35.
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-7c4684e124

Fixes this problem, thanks. Only 'fedora' and 'updates' repos can't be disabled, everything else can (including all flatpak repos).

Comment 37 Fedora Update System 2022-01-27 22:50:53 UTC
FEDORA-2022-7c4684e124 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-7c4684e124`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7c4684e124

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 38 Fedora Update System 2022-01-29 06:39:06 UTC
FEDORA-2022-7c4684e124 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.