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 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.
I dont think the article is fair.
Packagekit and dnf have different target audiences and acater towards them differently.
It is unfair to suggest that Packagekit in Fedora/DNF is incomplete or unstable due to the rewrite of dnf/libdnf – rewrites happen in software and often Fedora is the best place to sample Gnome Software, which uses Packagekit.
If a power user wants more control, DNF is a good option but for the end user the GUI tools in Gnome Software are good and the graphical distro upgrades through Gnome Software have been pretty impressive.
Looking to the future, I do not know if DNF will grow to be able to cope in the new world of flatpak, but Gnome software already handles this and support is improving.
However sometimes people will always prefer closer to the metal toold like DNF or alternatives in other distributions. That is not a knock on Packagekit or Gnome Software.
I agree with many of your points, but this is just wrong. The library itself says its incomplete. So I think its completely fair to say its incomplete.
I’ve yet to find a decent use for flatpack. There are definitely somethings that I think would make sense for it, but I’d have to go through the following process.
1) Figure out Linux set up to run ancient piece of software with crazy dependencies.
2) Port Flatpack back to that crazy distro setup.
3) Create a flatpack for that package.
I’m still kinda stuck on step 1, but step 2 looks heck of crazy amount of work as well.
Or there are a few flatpack build options built into some pieces of software, which I’ve tried and it all blew up in crazy error messages.
Note to other devs: If you want to support flat pack, provide a flatpack, not a make file that is supposed to produce a flatpack.
At the moment, my main interest in Flatpak is that, if you’ve got new enough versions of GTK+ and Qt, you’re supposed to be able to use the Flatpak launcher in “allow all” mode as a way to trigger common dialog indirection so all your applications can use the same Open/Save dialogs, regardless of what toolkit they’re written in.
Edited 2017-07-06 07:07 UTC
But then suggesting that by extension Gnome-Software or Packagekit are unstable is not correct.
It may be incomplete and there may be planned features or changes, or there may not. But that does not mean that Packagekit or Gnome-software are unstable because of it.
They may be unstable due to this or due to other reasons, but that assertion requires its own data points. Even a simple “I have found it unstable” would suffice.
Without that the question is are the interfaces unstable as they constantly change, without affecting the user, or does the user recieve a degraded experience.
Just to add that I often use DNF on the cli because it applies the updates without a mandatory reboot. There are good reasons to prefer DNF. I just found the article to be a little unfair.
Edited 2017-07-06 20:21 UTC
Basically, the libdnf backend for PackageKit on Fedora isn’t great right now, which obviously and unfortunately creates problems for the programs that use PackageKit again – like Gnome Software. He doesn’t say anything about Gnome Software or PackageKit in general being unstable; it’s a Fedora-specific complaint.
Edited 2017-07-06 23:29 UTC
It is libdnf, the backend for Packagekit and successor of libhif, which is incomplete because it lacks support of handling parameters like exclusion, autoremove to name new.
What gives you the idea that package managers won’t eventually support flatpak? Flatpak is just another package type, and the point of package managers is to automate downloading and installation of packages. DNF relies on the RPM tools to do the actual installation of the RPM packages, so it’s not a stretch to think it could be extended to include flatpak repos.
The better question is if flatpak is going to gain enough popularity to justify it’s inclusion.
I sure hope DNF doesn’t stand for Did Not Finish. Wouldn’t want that kind of reliability from a package manager.
Edited 2017-07-05 19:09 UTC
Yeah, not the best name. Some call it “DaNdiFied yum” It was at one point supposed to be a temporary name for the next version of yum, but they they just left the code name for reasons. Too late to change it now.
https://lwn.net/Articles/503581/
On Fedora/Red Hat and derivatives you have RPM as the lower level package DB and API and you have DNF as an abstraction of it. It offers a command line interface to the most common DB operations.
On Debian and alike you have DPKG for the lower level package DB and API and you have APT-GET as an abstraction of it.
Obviously, you also get PackageKit which is an abstraction of the abstractions (APT-GET and DNF), which by itself is ridiculous. APT-GET and DNF functionality should be moved into PackageKit and packagekit should get a CLI interface.
My take on this:
1) DNF should have been Yum-4.0
DNF is intended to be a rewrite of YUM, which is a rewrite of YAM and a replacement for up2date. It should have been simply called YUM-4.0. A rewrite of a piece of software that improves performance and adds new features is just a major version change, not a new package.
2) DNF should have proper PackageKit bindings
The DNF developers argue that every single application that does package management should be rewritten to support DNF instead of a writing a single plugin that extends PackageKit to DNF and not having to rewrite tens of applications.
3) Either APT-GET, Zypper and DNF shouldn’t exist with or PackageKit shouldn’t exist.
Red Hat and Canonical should move their asses and simplify the stack. Layering for the sake of layering is ridiculous, it’s not like you get a system that uses at the same time both APT-GET and DNF. If PackageKit isn’t good enough and DNF is better for managing this, either improve PackageKit or kill it.
We had a chance for unification a long time ago (in the redhat linux 9 era) when APT-GET was ported to RPM and was quite popular. But Red Hat wanted it’s own solution so they went with TerraSofts Yellow Dog Updater. I’m not saying that I like APT-GET more than YUM or DNF, but in the 13 years that have passed since then, it could have become great if all effort went into it.
Come to think about it if history would have sided strictly with the technologically advanced all distros would have been RPM + Apt-Get.
Like so many badly conceived Linux apps these days, PK doesn’t report errors or status or give you ANY way to find out why it hasn’t DONE ANYTHING for the last 15 minutes.
That’s why I’ve always used Yum and DNF on Fedora and apt get on Ubuntu / Debian.
Ever since Fedora switched to PackageKit it has periodically just stopped responding. The one time I dug into it with debuginfo-install and GDB it was stuck waiting for a network connection to exit, and they had somehow written a lovely bug in event loop code where the network socket was gone but there was some other notification socket in the select loop and so it just never exited.
Advice from MORONs online was to just reboot. What is this, Windows?
No, THIS IS LINUX!!!
/me boots PackageKit down a well.