Prepared updates are not supported by GNOME Software dnfdaemon backend #509
Labels
No labels
a11y
btrfs
Closed As
Can't fix
Closed As
Deferred to upstream
Closed As
Fixed
Closed As
Won't fix
default-apps
easyfix
experience
help-wanted
installation
meeting
meeting-request
nvidia
packaging
pending-action
qa
testing
user-docs
wg-docs
wg-meta
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
workstation/tickets#509
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In Fedora 44, GNOME Software has switched from PackageKit backend to a new downstream-only dnfdaemon backend. The new backend exists only in a downstream patch, which is not on track to land upstream because one of the upstream maintainers, Philip Withnall, is strongly opposed. (He recommends that we stick to the PackageKit backend instead.)
Unfortunately, I discovered over the weekend that my desktop had not received any software updates in more than 2 weeks. This is because I only update the system when an update is prepared, and prepared updates no longer work. GNOME Software's dnfdaemon backend does secretly prepare updates in the background, but due to technical limitations, it does not ever offer users to install the prepared update. Instead, users must manually open GNOME Software, click the Download button (which won't actually download anything: GNOME Software has already done that, it's just not reflected in the UI), and then click on "Restart & Update." GNOME Shell's end session dialog no longer prompts the user to install updates when powering off or rebooting.
Milan, the maintainer, says this is expected. But I am astounded: I didn't know about this, and it certainly does not match our designs for how software updates should work. I think most users will just no longer install software updates now that the handholding has been removed. Surely there's no way we would ever intentionally design software updates to work like this.
GNOME Software does present a desktop notification informing the user that updates are available. However, over the past decade we've trained users to ignore those: by allowing updates to be installed from the end session dialog, users can safely ignore update notifications, keep using the computer, and then power off or reboot whenever they are done working.
Yesterday, I asked Milan to revert back to GNOME Software's PackageKit backend (we did this once before, for Fedora 43), but he doesn't want to. So today in Matrix I presented an extraordinary request to the Working Group: overrule Milan and declare that we will stick to PackageKit backend for F44. We did this hastily and without the full Working Group present, due to very tight timing constraints: go/no-go is tomorrow, and there was almost no time. Our vote to revert was: +2 (Michael, Neal), -4 (Matthias, Tomas, Jens, Nieves). I don't have votes from Chris or Allan due to the hasty nature of the discussion, but even if they were present, the proposal could not have passed due to the four negative votes. So unfortunately Fedora 44 will only support semi-manual updates.
The negative votes are understandable because a last-minute revert is inherently risky. PackageKit has switched from dnf4 to dnf5. We could release with completely unknown bugs. But Neal is confident that it will work well: we know it works fine for Plasma Discover, and he has also tested it for GNOME Software before. I think the risk that we discover new bugs is clearly outweighed by the cost of not having functional prepared updates.
Now I am asking the full Working Group to consider the issue on our standard non-emergency timeline. Given that we'll ship with dnfdaemon backend, and the first update will require manual intervention, it would still be nice to require that users update manually only once. We can release an early F44 update reverting GNOME Software back to the PackageKit backend. This allows us a little time to test to make sure there are no serious problems, so hopefully it will be better-received than my rejected emergency proposal.
As I will not make it for the next couple of meetings due to traveling, I'll reiterate my position that we should switch back to PK-DNF5 for GNOME Software.
The dnf5daemon backend will not be accepted upstream, and as the developer/maintainer of PackageKit and PK-DNF5, I'm here to responsively deal with issues as I can. PK-DNF5 has also been tested with GNOME Software with Fedora Asahi Remix, since it shipped with Fedora Asahi Remix 43.
I'll also note we had no Change to announce switching to dnf5daemon backend for GNOME Software, so nobody was actively looking at it like people were for PK-DNF5 with Plasma Discover. I only found out we were doing this in the discussion for the PK-DNF5 Change.
Let me comment on few things, because seeing a false statement is not great.
Starting with the title: "Prepared updates are not supported" - that's wrong. The gnome-software is supposed to download updates to be (quickly) installed when the user can. It happens. Hence they are supported.
Be more specific, please. You rely on the gnome-shell's endSessionDialog. The gnome-software notified you every day you should update, but you ignore that notification.
I guess you mean that as a comment to what I wrote to the bug. I never said there is a limitation, I said there are differences.
I did look on the internals after I wrote that comment in the bug, and the dnf5daemon does things right. I'd like to get one little thing added to the deamon, which would make my life much easier, but even if they'd not add it "quickly", I can still make it work just by a (slightly bigger) change on the gnome-software side.
The DNF team is planning to get that one little thing done within a week.
Milan has been working on this. Apparently it was easier to fix than I had expected. So, we may not need to discuss this after all, and certainly not this week.
This issue is not fixed yet, but I am confident it will be resolved soon, either via freeze exception or via a 0-day update. Thank you, Milan and dnf team!