It’s probably no surprise to many of you that PackageKit has been in maintenance mode for quite some time. Although started over ten years ago (!) it’s not really had active maintenance since about 2014. Of course, I’ve still been merging PRs and have been slinging tarballs over the wall every few months, but nothing new was happening with the project, and I’ve worked on many other things since.
I think it’s useful for a little retrospective. PackageKit was conceived as an abstraction layer over about a dozen different package management frameworks. Initially it succeeded, with a lot of front ends UIs being written for the PackageKit API, making the Linux desktop a much nicer place for many years. Over the years, most package managers have withered and died, and for the desktop at least really only two remain, .rpm and .deb. The former being handled by the dnf PackageKit backend, and the latter by aptcc.
Canonical seems to be going all in on Snaps, and I don’t personally think of .deb files as first class citizens on Ubuntu any more – which is no bad thing. Snaps and Flatpaks are better than packages for desktop software in almost every way. Fedora is concentrating on Modularity and is joining with most of the other distros with a shared Flatpak and Flathub future and seems to be thriving because of it. If course, I’m missing out a lot of other distros, but from a statistics point of view they’re unfortunately not terribly relevant. Arch users are important, but they’re also installing primarily on the command line, not using an abstraction layer or GUI. Fedora is also marching towards an immutable base image using rpmostree, containers and flatpaks, and then PackageKit isn’t only not required, but doesn’t actually get installed at all in Fedora SilverBlue.
GNOME Software and the various KDE software centers already have an abstraction in the session; which they kind of have to to support per-user flatpak applications and per-user pet containers like Fedora Toolbox. I’ve also been talking to people in the Cockpit project and they’re in the same boat, and basically agree that having a shared system API to get the installed package list isn’t actually as useful as it used to be. Of course, we’ll need to support mutable systems for a long time (RHEL!) and so something has to provide a D-Bus interface to provide that. I’m not sure whether that should be dnfdaemon providing a PackageKit-compatible API, or it should just implement a super-simple interface that’s not using an API design from the last decade. At least from a gnome-software point of view it would just be one more plugin, like we have a plugin for Flatpak, a plugin for Snap, and a plugin for PackageKit.
Comments welcome.
As I remember, PackageKit have many nice features, like installing fonts system-wide by normal users. There’s no competitors in such case.
Sure, we don’t want to loose that.
In Yelp, we have (very minimal) PackageKit integration that allows docs to have buttons that install packages. Do you have a recommendation for what that should look like going forward?
Could we integrate in gnome-software?
Probably. IIRC, all we do is a fire-and-forget “install this package” call, and gnome-software ends up handling the rest anyway.
As the lead of one of those smaller independent distros, this does make me a little sad, but I suppose I can understand that it isn’t a priority for you any more.
.debs are still very much used on Debian, and there are certainly other package formats extant on the desktop – Arch .pkg, Adélie .apk, Gentoo .tbz2 are a few that come to mind. But we’re certainly the minority, at least for now.
We at Adélie may end up forking PackageKit, or perhaps just using it in its current state – I don’t even remember when the last time was that I actually saw a bug in it.
Thank you so much for your work maintaining it. It has been greatly appreciated. Best wishes on your other endeavours; and since you also manage UPower, we may cross paths again. :)
IMO it’d be best just to focus on gnome-software an eventually Remove/retiree Packagekit all together , question is DNFDragora wont that see the same Fate as Packagekit
The depressing thing about this announcement is that we _just_ finally managed to get all the major distributions to care enough to integrate PackageKit properly.
Now what? We need a new implementation for each thing again? There’s a large world of things that talk to PackageKit for the purpose of easily handling basic tasks.
Killing PackageKit is going to be a huge mess, and I’m saying this as the current maintainer/developer of dnfdaemon…
Nobody is ready for this.
I’m not killing it, I’m still planning on doing maintenance. I’ve just been explicit to manage expectations.
Just a note: Not all major Linux distributions use PackageKit, for example Linux Mint still uses aptdaemon. :)
> Fedora is concentrating on Modularity and is joining with most of the other distros with a shared Flatpak and Flathub future and seems to be thriving because of it.
I actually don’t know of any distributions that are focusing or shipping Flathub. And it is unlikely that will change with the way things are today.
I considered enabling Flathub out of the box for Mageia, but generally our users and developers prefer people to use the software we’re building and shipping.
And as for Fedora Modularity, that’s specifically managing software shipped as RPMs! So, I don’t know what you’re thinking here, because there’s nothing relevant about modularity in this idea that “RPMs are dead”.
There are also two frontends for RPM that have actively maintained backends: DNF and ZYpp. So I think it still very much matters from that perspective. Yes, it’s not 5 or 8 of them like in years gone by, but it’s still more than one.
I can’t really speak much for the Ubuntu side, though…
“I actually don’t know of any distributions that are focusing or shipping Flathub”
Just from the top of my mind: Linux Mint, EndlessOS
But there is definitely more.
So there are distributions, just none of the major ones…?
Arch Linux shippps flathub if you install flatpak
Manjaro comes with flatpak und flathub preinstalled
Well, this is awkward. We were just about to start another attempt at migrating Ubuntu tools to PackageKit. We still have a ton of stuff on aptdaemon that we were looking forward to having work on PackageKit instead.
These are not basic tasks either, for example, update-manager might very well exceed what PackageKit is capable off and need more features.
I guess we’ll have to take a step back and look at our options again if PackageKit is going to stagnate.
It’s been stagnating for years. I’m still going to do releases, but I’m really not sure the future for Ubuntu should be PackageKit. I thought everything was Snap, Snap, Snaps?
Well, snaps are the focus I guess. Does not mean we don’t need to be able to upgrade deb systems, install drivers, or stuff like that from graphical interfaces.
I think an awesome approach would be to make APT library work as non-root, so we can just write normal APT programs and they automagically talk to an apt daemon via dbus if running unprivileged.
I still think there is some value for abstracting package managers, but I really prefer that in the form of a library rather than a dbus daemon; so you can write faster apps that access the package manager caches in process vs wiring everything over dbus.
The problem is the issue of managing access to caches. PackageKit being a daemon means that only one thing is writing to the cache and many things can access the data from PackageKit, even unprivileged.
Even yumdaemon/dnfdaemon and aptdaemon more or less behave the same way.
Making the DNF library (libdnf) or the APT library (libapt-pkg) work from non-root would require something to live in the middle to make non-root work properly.
Since we already have PackageKit, we should just use that. And most of the ecosystem has built around PackageKit.
For the most part, PackageKit is “completed software”. There’s really not much more functionality that needs to be added. The backends are in varying states, but the functionality of PK is pretty much done.
I personally do not want to do another attempt at making a multiple package manager backends in something. I don’t really want to integrate the library in a ton of places, and I really don’t want to redo everything in PackageKit again.
I imagine most of us who have worked on PackageKit integration stuff feel that way.
“PackageKit is a complete software”, but the world is marching. Rpm depsolver is AFAIK different from DNF at it is causing issues. There are new features (ehm modularity) which need to be implemented. So I guess that PackageKit is dead unless it get new active upstream maintainer.
Speaking as a maintainer of Fedora Design Suite labs, it is quite shocking to hear PackageKit wasn’t actively maintained for years as it simplifies the commands and was one crossplatform backend command regardless the distribution.
What does that mean for systemupgrades in Gnome-Software? For example I run Arch Linux for my whole family for 2 years, they do system upgrades via Gnome-Software (that seems to be based on packagekit).
Will this just vanish or is there a replacement?
Because it’s sad to read this, when finally many distros have appstream support for “native” packages and packagekit is kind of a critical part of the linux desktop now.
This kind of feature will continue. On SilverBlue it already works without PackageKit.
But will it keep working or does something need to write a pacman/alpm-gnome-software plugin to make it work. Because in case of the last option, this will probably never happen.
“and I don’t personally think of .deb files as first class citizens on Ubuntu any more – which is no bad thing.”
You are technically correct, it isn’t a bad thing. It is a horrifically awful thing. I mean, for Ubuntu. I use Debian which hasn’t lost its mind.
Please, please update this blog post and make it clear that there is no reason to abandon PackageKit! It is super useful and there is no reason why people should stop using it.
Snaps and flats and stuff are relatively new and hype and I doubt that .debs and .rpms will get obsolete as fast as you describe.
If you need help or want to hand over the project then just ask for it. I’m sure there is somebody to take it, worst case I brush up my C skills and do it myself.
It’s kind of sad, that PackageKit is stagnating. However, a lot of thanks for bringing it so far and keeping it alive.
Discover (KDEs very actively developed PackageKit-Frontend) is for me the only way to get non-technical people (e.g. my parents) into actually using the package management and doing updates! The last point is the most important one. Of course I can configure some sort of auto update, but PackageKit is making the package management simply usable (they use OpenSUSE btw). And of course a lot of distributions are pushing their “here-is-my-application-with-all-libraries”-packages, but do you think, this will replace the deeper levels of software and packages? And for this software you want to be have an GUI update mechanism, too.