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.
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.
For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team.
For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team.
For help debugging failed openQA tests (update.*), contact the Fedora Quality team, who will usually investigate and diagnose all failures within 24 hours.
This update was automatically created
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
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...
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.
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.