Description of problem: GNOME Software has an implicit require on libpackagekit-glib2.so.18 which causes the PackageKit-glib package to be installed on Silverblue which in turn causes issues when other software are installed and pull the full PackageKit package which in turn causes issues with GNOME Shell wrongly assuming that PackageKit is available. Initial report in https://github.com/fedora-silverblue/issue-tracker/issues/203 Version-Release number of selected component (if applicable): Latest from F34 How reproducible: ? Steps to Reproduce: 1. Install cockpit on Silverblue 2. PackageKit gets installed as a dependency Actual results: GNOME Shell stall on logout, etc. Expected results: No stall as PackageKit does not get pulled in. Additional info: https://github.com/fedora-silverblue/issue-tracker/issues/203
Thanks for a bug report. Are you sure you wanted to fill this against gnome-software, not against cockpit? The cockpit brought in the PackageKit, not gnome-software, thus the logic place would be the cockpit. It's true gnome-software brings in the PackageKit-glib, but that doesn't install PackageKit. The gnome-software-rpm-ostree subpackage is installed only on the Silverblue. It's defined as: %package rpm-ostree Summary: rpm-ostree backend for gnome-software Requires: %{name}%{?_isa} = %{version}-%{release} Requires: rpm-ostree%{?_isa} Supplements: (gnome-software%{?_isa} and rpm-ostree%{?_isa}) Maybe the cockpit-packagekit might do a similar thing, only for the PackageKit package, not for the rpm-ostree package. The rpm-ostree plugin also checks for an existence of a "/run/ostree-booted" file. If not there, the plugin disables itself. Otherwise it "takes over" the PackageKit plugin (of the gnome-software). That could be the change on the gnome-shell side, to ignore PackageKit, when the "/run/ostree-booted" file exists.
I'm not 100% sure this is the reason the package is installed but this is my most likely guess as PackageKit-glib is not installed on either Fedora Kinoite or CoreOS and installing cockpit there does not bring the cockpit-packagekit & PackageKit package as deps. $ sudo dnf repoquery --whatrequires PackageKit-glib PackageKit-0:1.2.4-2.fc35.x86_64 PackageKit-command-not-found-0:1.2.4-2.fc35.x86_64 PackageKit-glib-devel-0:1.2.4-2.fc35.i686 PackageKit-glib-devel-0:1.2.4-2.fc35.x86_64 PackageKit-gstreamer-plugin-0:1.2.4-2.fc35.x86_64 PackageKit-gtk3-module-0:1.2.4-2.fc35.x86_64 gnome-packagekit-common-0:3.32.0-8.fc35.x86_64 gnome-packagekit-installer-0:3.32.0-8.fc35.x86_64 gnome-packagekit-updater-0:3.32.0-8.fc35.x86_64 gnome-software-0:41.0-1.fc35.i686 gnome-software-0:41.0-1.fc35.x86_64 simple-scan-0:40.5-1.fc35.x86_64 I don't think this is an issue with the Cockpit package as it correctly uses Recommends for PackageKit: https://src.fedoraproject.org/rpms/cockpit/blob/rawhide/f/cockpit.spec#_424 Adding a check for "/run/ostree-booted" in the PackageKit code path in GNOME Shell could be a simple solution / workaround.
The cockpit-packagekit requires the PackageKit package: https://src.fedoraproject.org/rpms/cockpit/blob/rawhide/f/cockpit.spec#_700 The question is why cockpit-packagekit had been installed this time. You did not mention it from your "transcript" from the Silverblue issue. Why it brings the cockpit-packagekit in one installation and not in another I do not know, it's decided on the dnf side, according to the user preferences. See the info about the weak dependencies at: https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
cockpit-packagekit really requires PackageKit. Certainly on OSTree you wouldn't want to install cockpit-packagekit even, nor cockpit-ws (it's better to run the web server as cockpit/ws container then). The "cockpit" metapackage has a recommens: cockpit-packagekit, as on the rpm-based Fedora that's the right thing. What is the original scenario/bug here? The bug description here is apparently unrelated.
A bit more detailed info is in the Silverblue tracker, in case you did not follow it from the description: https://github.com/fedora-silverblue/issue-tracker/issues/203
I don't have a SilverBlue installation handy -- could someone please check if "dnf" is installed there? If not, then I propose to make the recommendation conditional: Recommends: (cockpit-packagekit if dnf) That way, it is not auto-installed on CoreOS/Silverblue. That's similar to the existing `Recommends: (cockpit-storaged if udisks2)` that we already have for similar reasons.
(In reply to Martin Pitt from comment #6) > I don't have a SilverBlue installation handy -- could someone please check > if "dnf" is installed there? If not, then I propose to make the > recommendation conditional: > > Recommends: (cockpit-packagekit if dnf) > > That way, it is not auto-installed on CoreOS/Silverblue. That's similar to > the existing `Recommends: (cockpit-storaged if udisks2)` that we already > have for similar reasons. dnf isn't installed by default, however it can be manually installed to search for packages in repositories and enabling copr repos.
Done in https://github.com/cockpit-project/cockpit/pull/16424
(In reply to Martin Pitt from comment #8) > Done in https://github.com/cockpit-project/cockpit/pull/16424 But what if user will install dnf manually?
> But what if user will install dnf manually? Then the situation is as before. Most users won't do that (that's what toolbox is for). There is only so much expressiveness in package dependencies..
As per comment #2, I don't think the root issue is in cockpit but what you did could help as dnf is indeed not expected to be installed on rpm-ostree base systems.
FEDORA-2021-a7a8407de1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7a8407de1
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
Oops, this got fixed long ago, the bodhi update just didn't auto-close it.