PackageKit 2.0 is being planned with a complete break of every interface the project exposes, interfaces that have been frozen for more than a decade. The work is part of a broader Freedesktop modernisation effort funded through a Sovereign Tech Fellowship.

What PackageKit is

Most people have never heard of it and most desktop Linux users depend on it. PackageKit is the abstraction layer that lets GNOME Software and KDE Discover install packages without knowing whether the system underneath uses apt, dnf, zypper, or something else.

Without it, every graphical software centre would need a backend per distribution. With it, they target one API.

Why break everything

A frozen API is a good thing for consumers and a slow accumulation of debt for maintainers.

Design problems that could not be fixed without breaking compatibility got worked around instead, and those workarounds are now load-bearing. Obsolete features that nobody uses still have to be supported because removing them would break the contract. New capabilities that frontends want cannot be added cleanly because the shape of the interface does not accommodate them.

Ten years of that produces a codebase where the right fix is unavailable and the wrong fix is mandatory. Breaking the API is how you stop paying that tax.

The stated intention is to build on PackageKit 1.0’s foundation while simplifying the code, removing obsolete functionality, and adding capabilities frontends have wanted.

Offline updates get revisited

The more visible change for users concerns offline updates: the mechanism where a graphical updater downloads packages, reboots into a minimal environment, applies them, and reboots again.

The reasoning behind it is sound. Updating a running desktop while its libraries are being replaced underneath it is how you get a session that misbehaves in ways nobody can reproduce. Applying updates when almost nothing is running avoids that entirely.

The cost is two reboots and a wait, which is a noticeably worse experience than a package manager that just updates.

The plan is to revisit it using newer systemd features, specifically soft-reboot, which restarts userspace without going through firmware and the bootloader. That could turn a multi-minute two-reboot cycle into something considerably shorter.

The transition question

An API break means every consumer has to be updated. GNOME Software, KDE Discover, and every distribution backend need work before 2.0 is usable, and both APIs will likely coexist for a while.

That is the honest cost, and it is the reason projects avoid breaks for a decade in the first place. The developers say they expect it to be worth it, which is the correct framing: this is deliberate debt repayment rather than a rewrite for its own sake.

Context

It lands alongside other package management modernisation. RPM 6.1 adopted a kernel-style release model and PKCS#11 signing this month, APT 3.3.3 began building an interactive help system, and Shelly 3.1 took over the full build pipeline on Arch.

Package management is having an unusually active year for a part of the stack most people consider settled.