Using gnome-software-49~beta-6.fc43, go to the Updates page and click the Download button. Wait for a prepared update to be installed. When the "Restart and Install" button appears, do NOT click it. Just reboot or power off the system normally. During the next boot, offline updates will be unexpectedly installed. Updates should never be installed except when the user explicitly consents to it, either by pressing "Restart and Install" or by shutting down using gnome-shell's end session dialog, which has a checkbox to display whether to install updates. Reproducible: Always
Proposed as a Blocker for 43-final by Fedora user catanzaro using the blocker tracking app because: The default graphical package manager for a given software type must *appropriately*: Install, remove and update software Emphasis on "appropriately." If you don't like this choice of criterion, there's always basic application functionality criterion to fall back on.
Well, it depends. For two reasons. How much is this a personal opinion? Because other users might think the opposite, like here: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2619 Anyway, when I use dnf5daemon-server-5.2.16.0-3.fc44.x86_64 gnome-software-49~rc-1.fc44.x86_64 I cannot reproduce this. After fighting with dependencies (bug #2392314) and disk space, when I click the "Download" button in the Updates tab of the gnome-software is downloads the packages and lets me click "Restart & Update...". There is no `/system-update` symlink at this time. When I click on it I'm asked to restart the machine, while there's also added `/system-update` symlink in the file system. When I cancel the restart prompt the symlink is removed. I changed this behaviour very recently. > by shutting down using gnome-shell's end session dialog, which has a checkbox to display whether to install update That checkbox works only for PackageKit, see: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7784 and https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2307 (I cannot tell whether the later will be accepted or not, it's only a proposal)
I could reproduce this issue with some older F43 version, but with current stable packages: dnf5daemon-server-5.2.16.0-3.fc43.x86_64 gnome-software-49~beta-5.fc43.x86_64 nor with current updates-testing packages: dnf5daemon-server-5.2.16.0-3.fc43.x86_64 gnome-software-49~rc-1.fc43.x86_64 I can no longer reproduce this issue. So I think it's resolved. Michael, can you confirm?
+5 in https://pagure.io/fedora-qa/blocker-review/issue/1894 , marking accepted.
(In reply to Milan Crha from comment #2) > Well, it depends. For two reasons. How much is this a personal opinion? > Because other users might think the opposite, like here: > https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2619 I'm not sure that issue report is related at all? My personal opinion is that updates must not be installed without user consent. Too much can go wrong. Imagine shutting down the system due to low battery power and GNOME Software decides "I update now!" Or maybe it's right before an important conference presentation, and you don't want to update for fear of breaking something. Anyway, doesn't matter, because I tested this again and the bug seems to be fixed, as Kamil suggests. So we can just close this. (In reply to Milan Crha from comment #2) > That checkbox works only for PackageKit, see: > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7784 and > https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2307 (I > cannot tell whether the later will be accepted or not, it's only a proposal) Please treat this as a blocker for shipping the new dnf backend in F43, i.e. we probably need to switch back to PackageKit if this isn't ready *really* soon. (But it's not a Fedora release blocker.)
> Please treat this as a blocker for shipping the new dnf backend in F43 There is literally no time to add dnf5 offline update check into the gnome-shell, especially at this stage. The dnf5 works differently than PackageKit. That's quite common. It's not like different WebKitGTK versions ;) The dnf5 plugin currently downloads the updates, but does not auto-prepare them. Anyway, I do not mind myself. If the Workstation Working Group and/or FESCO will decide to do it, then yes, I can switch back to the PackageKit backend. You might probably consider asking also people pushing to use the dnf5 backend, I guess.
Please switch F43 back to PackageKit backend. The folks who are pushing to use the dnf5 backend are well aware that delays are possible, and hopefully should be pleased to see how much progress you've made so quickly. Hopefully it will ship it F44. :)
Might it be better to not have it as a single person decision to include or not the work? The decision to include it was made by multiple people (as a Change proposal within dnf5 work) and I already was late due to missing APIs and fine-tuning the behaviour on both dnf5 and the plugin sides. Dropping the work (also in the Fedora QA) might be good to be blessed somehow, I guess. I do not mean a Change proposal, I mean just, you know, more voices.
*Is* this actually a Change? I can't find it in https://fedoraproject.org/wiki/Releases/43/ChangeSet . Anyhow, if we're going to revert it, we should revert it for Beta, and that will require an FE. So I've filed an FE proposal and that can provide a venue for discussion: https://bugzilla.redhat.com/show_bug.cgi?id=2392062#c7 . Please CC anyone you think should chime in on that bug.
sorry, correct FE link - https://bugzilla.redhat.com/show_bug.cgi?id=2392645
As I mentioned, the dnf5 plugin work lacked behind, due to missing pieces on the dnf5daemon-server side. The change I have on my mind is: https://fedoraproject.org/wiki/Changes/SwitchToDnf5 (an f41 material, that much behind I am).