Linked by Thom Holwerda on Wed 5th Jul 2017 17:13 UTC
Fedora Core

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.

Order by: Score:
Unfair article
by VistaUser on Wed 5th Jul 2017 17:27 UTC
VistaUser
Member since:
2008-03-08

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.

Reply Score: 2

RE: Unfair article
by Bill Shooter of Bul on Wed 5th Jul 2017 17:54 UTC in reply to "Unfair article"
Bill Shooter of Bul Member since:
2006-07-14

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.


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.

Reply Score: 2

RE[2]: Unfair article
by ssokolow on Thu 6th Jul 2017 07:06 UTC in reply to "RE: Unfair article"
ssokolow Member since:
2010-01-21

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

Reply Score: 2

RE[2]: Unfair article
by VistaUser on Thu 6th Jul 2017 20:15 UTC in reply to "RE: Unfair article"
VistaUser Member since:
2008-03-08

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.


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

Reply Score: 2

RE[3]: Unfair article
by dnebdal on Thu 6th Jul 2017 23:27 UTC in reply to "RE[2]: Unfair article"
dnebdal Member since:
2008-08-27

But then suggesting that by extension Gnome-Software or Packagekit are unstable is not correct.


That's not really what he said, though.

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. 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.


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

Reply Score: 2

RE: Unfair article
by Finalzone on Wed 5th Jul 2017 19:30 UTC in reply to "Unfair article"
Finalzone Member since:
2005-07-06

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.

Reply Score: 3

RE: Unfair article
by Flatland_Spider on Thu 6th Jul 2017 15:31 UTC in reply to "Unfair article"
Flatland_Spider Member since:
2006-09-01

I dont think the article is fair.


It's a fair article. PackageKit has deficiencies that yum/dnf or Yumex/Yumex-DNF do not, and the article lists valid criticisms. It's little areas which need polishing to improve the layperson's desktop experience.

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.


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.

Reply Score: 2

As a motorsport fan...
by gan17 on Wed 5th Jul 2017 19:06 UTC
gan17
Member since:
2008-06-03

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

Reply Score: 3

RE: As a motorsport fan...
by Bill Shooter of Bul on Wed 5th Jul 2017 21:08 UTC in reply to "As a motorsport fan..."
Bill Shooter of Bul Member since:
2006-07-14

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/

Reply Score: 2

It's just a bad excuse
by d3vi1 on Thu 6th Jul 2017 20:24 UTC
d3vi1
Member since:
2006-01-28

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.

Reply Score: 1

PackageKit is a pile of failure
by zlynx on Fri 7th Jul 2017 19:45 UTC
zlynx
Member since:
2005-07-20

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.

Reply Score: 2