testing

gnome-software-48.1-2.fc43

FEDORA-2025-4a9607a2d0 created by mcrha 3 weeks ago for Fedora 43

Automatic update for gnome-software-48.1-2.fc43.

Changelog
* Tue Apr 29 2025 Milan Crha <mcrha@redhat.com> - 48.1-2
- Switch from PackageKit to DNF5 plugin

This update was automatically created

3 weeks ago

This update's test gating status has been changed to 'waiting'.

3 weeks ago

This update's test gating status has been changed to 'failed'.

3 weeks ago
User Icon adamwill commented & provided feedback 2 weeks ago
karma

So this fails because we now prompt for authentication to run an update. This doesn't happen with PackageKit because there's a polkit policy that allows wheel group members to install some packages via PackageKit without re-authenticating (it's something like "packages signed with a trusted key" or "packages from an enabled repo", we're not exactly sure what the rule is ATM).

that rule has always been a bit controversial, but every time it's come up for discussion we've ultimately kept it, I guess because we want operations like system updates and installing an app from GNOME Software or KDE Discover to be seamless.

to preserve existing behaviour we could have a polkit rule for dnf which acts the same way. This would still be a change in some sense, though, because until now, if you didn't like this policy, you could remove PackageKit from your system entirely - that's plausible to do, especially on a non-desktop system. You can't really get by without dnf, though. So if we bake in such a rule for dnf, everybody is stuck with it unless they actually write an override policy. Perhaps we could package up an overriding policy for people who want tighter behaviour, or something.

I don't know why we didn't catch this in the pre-testing we did, sorry. I was really sure I checked those logs to make sure the updated packages were tested, but something must have gone wrong...

I don't know why we didn't catch this in the pre-testing we did, sorry.

That's okay. I discuss this with the dnf5 folks and we'll come up with something soon. I do not want to drop this update for now, because the change will be elsewhere, but I can do it if needed.

Alternatively, might gnome-software provide that policy (wheel can update without asking) instead of the dnf5 itself? Then one can drop gnome-software to get rid of that policy. I guess a 3rd-party package can add a polkit policy influencing the dnf5daemon-server.

I took the liberty of quickly writing a polkit rule here, and now gnome-software updates without requiring the user to authenticate again, as long as the user is in the "wheel" group.

cat << EOF > /etc/polkit-1/rules.d/00-gnome-software.rules
polkit.addRule(function(action, subject) {
    if (action.id == "org.rpm.dnf.v0.rpm.execute_transaction" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});
EOF

Thanks for the rule. I'll check with the dnf5 folks. It can have side effects, as this can let the wheel user run any transaction, which may or may not be a problem. I'm not sure whether PackageKit did this too or not for the wheel user, I only believe it's not appreciated by some of the users. I'll let here know when I know more.

Looking at the polkit files on F42, which still uses PackageKit, I found a rule very similar to the one I created hahaha.

cat /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules
polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.packagekit.package-install" ||
         action.id == "org.freedesktop.packagekit.package-remove") &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }
});

Please log in to add feedback.

Metadata
Type
unspecified
Karma
-1
Signed
Content Type
RPM
Test Gating
Autopush Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
0 days
Thresholds
Minimum Karma
+0
Minimum Testing
0 days
Dates
submitted
3 weeks ago
in testing
3 weeks ago

Automated Test Results