Bug 2008154

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.