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
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
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
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...
> 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...".
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?
Upstream issue: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1479
> 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".
> 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.
> 'fedora-cisco-openh264' This one too: users should be able to opt-out.
> 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.
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
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.
(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.
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).
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.
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?
(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.
> 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).
> 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
> 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.
I sat only [ 'fedora', 'updates' ] as the "required-repos" in the .spec file. If more/others are needed, just let me know.
FEDORA-2021-979587cebf has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-979587cebf
Milan: thanks a lot!
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.
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.
Verified fixed with gnome-software-41.0-5.fc35.
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.
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.
Tracking this against the F36FinalBlocker, so that we don't lose sight of it.
I see I dropped those extra patches accidentally when making 41.1 release. I'll return them back.
I forgot to mention, those patches are already part of the 42.x, which is in rawhide, thus also in the upcoming f36.
(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.
FEDORA-2022-7c4684e124 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7c4684e124
(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).
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.
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.