Fedora Workstation comes with two package managers by default: DNF and PackageKit. DNF has all the latest features and the best support, but PackageKit is put front and center in GNOME Software, KDE Plasma Discover, and as of Fedora Linux 26 also in Cockpit’s new Software Update panel.
You may be better off sticking with the DNF package manager in the command-line; even though PackageKit is the choice of all the graphical package managers. Here is some of the advantages DNF still gives you over PackageKit based applications.
PackageKit is part of the magic that makes GNOME Software Center and KDE Plasma Discovery — the two most widely used “app stores” on Linux — work across different Linux distributions despite each having their own package manager.
The idea behind PackageKit is to provide a cross-platform front-end and API layer for common operations in popular Linux package managers such as APT for Debian and Ubuntu, DNF for Fedora and RHEL, Zypper for openSUSE and SUSE, and Pacman for Arch Linux. Other package managers and distributions are supported as well. That is to say, you can use the same command-line interface — or programming API — for interacting with the host operating system’s package manager regardless of the distribution or underlying package manager.
However, PackageKit in Fedora Linux isn’t great. It relies on the still in-development libdnf library which is a fairly new effort to port DNF from Python to C. To quote the library’s own README file:
Note that libdnf is currently being reworked and is considered unstable. Once major users like PackageKit and DNF are fully ported, a new stable release will be considered.
In other words: GNOME Software and Plasma Discover, two front-and-center applications for end-users on Fedora Workstation (and the Fedora KDE Plasma Desktop edition), rely on an unfinished work-in-progress library on Fedora Linux. It’s worth noting here that both the Pacman backend for Arch Linux and APT backend for Ubuntu seem to be in a much better shape than the DNF backend in PackageKit.
Problems quickly show up when comparing pkcon and dnf, the command-line interfaces of PackageKit and DNF respectively:
The command-line dnf utility can automatically identify and remove orphaned packages — unused libraries and other packages — when you upgrade or remove software. PackageKit will simply leave the orphaned packages installed and even keep updating them in the future even though the library sits there without any software ever using it.
libdnf and PackageKit don’t yet support downloading delta RPMs. Which results in PackageKit requiring up to three times more network bandwidth and data usage to keep the system up-to-date compared to updating with delta RPMs. (The exact figures depends on the which packages you’ve installed on your system – and how they’re updated.)
Both libdnf and PackageKit ignores the /etc/dnf/dnf.conf configuration file which lets users enable features in DNF such as automatic-fastest-mirror-selection, package exclusions, and control network utilization. Not being able to configure package exclusions with PackageKit can be very disruptive to your workflow depending on your use for excluding certain packages.
The DNF backend for PackageKit in Fedora Linux also lacks safeguards to prevent users from uninstalling crucial packages such as glibc, dnf, libdnf, and indeed PackageKit itself. These are in place for other backends, including DNF’s predecessor Yum, but are marked as “TODO” for DNF. The dnf command-line interface, however, does protect a shortlist of critical packages – including itself — from being removed.
In conclusion: All graphical package managers/app stores in Fedora Linux 25 and 26 currently give you less control over your packages, use more time and bandwidth to update, and leave behind unused dependencies when you uninstall packages.
Stick with dnf on the command-line for the best experience – albeit without a graphical interface. Take a minute to set up automated updates with DNF automatic if you want to be less involved with your package manager.
I’m likely to reverse this recommendation and suggest you embrace PackageKit once libdnf and PackageKit support more of DNF’s functionality at some point in the future. Learning PackageKit is a “portable skill” that you’ll find useful even when you find yourself on an unfamiliar Linux distribution.