pkgcli: Reimagining the Command Line for Linux Package Management

The Linux command line has always been a place where tools either earn their keep or become forgotten relics. For almost twenty years, pkcon occupied that second category. The PackageKit daemon, which provides a hardware-agnostic abstraction layer for package management across multiple distributions, shipped with a command-line client that never quite felt finished. Its commands mirrored D-Bus API method names one-to-one, its output was austere, and there was no structured output mode for scripting. Development on pkcon effectively froze around 2015, leaving it frozen in a state that reflected the command-line sensibilities of a decade earlier while the rest of the ecosystem moved on.

PackageKit itself was always somewhat underappreciated. While distributions leaned toward their own native tools, PackageKit provided a consistent API layer that GUI software centers, automatic update daemons, and system integration tools could depend on without locking into the specifics of apt, dnf, or pacman. The daemon was capable and well-maintained. Its command-line interface simply was not.

The Problem with pkcon

The fundamental issue with pkcon was one of origin. It was built as a testing tool for the PackageKit daemon rather than as a production interface for end users. Its command names, like get-details, get-updates, and get-depends, read like D-Bus method invocations rather than descriptions of what you want to accomplish. You were not asking the system to show you information about a package; you were invoking a remote procedure call by name. This created a layer of indirection that made the tool feel mechanical rather than expressive.

Beyond naming, pkcon lacked any concept of machine-readable output. For interactive use, its plain text output was functional but unpolished. For scripting, it was nearly useless. There was no JSON mode, no structured output, no way to pipe results into jq or parse them with standard Unix tools without resorting to fragile text processing.

Most critically, pkcon had seen no meaningful development in nearly a decade. As PackageKit itself continued to evolve, its primary CLI tool remained frozen, unable to take advantage of improvements in the daemon or changes in how users expected to interact with their systems.

A New Tool, Not a Patch

The decision to build pkgcli rather than extend pkcon reflects a mature understanding of backward compatibility. The old tool's command-line API had ossified. Changing its command names, output format, or default behavior would break existing scripts and workflows. Rather than risk that disruption, the new tool was introduced as a clean slate.

pkgcli was developed as part of the Sovereign Tech Agency fellowship, an initiative focused on funding critical digital infrastructure that often goes unacknowledged. PackageKit, as a foundational layer for many Linux desktops, fits squarely into that category. The work was motivated by practical necessity: upcoming changes to PackageKit required a more capable tool for testing and development, and the existing pkcon was simply not up to the task.

What Changed and Why It Matters

The design philosophy of pkgcli is immediately apparent in its command structure. Instead of get-details, you use show. Instead of get-updates, you use list-updates. Instead of search with hidden subcommands, you get straightforward verbs like search name that read naturally. The tool communicates what you want to accomplish rather than which D-Bus method you are invoking.

The output was also reconsidered from scratch. pkgcli prints colored, formatted output by default, with proper alignment that handles internationalized text correctly. It respects the NO_COLOR environment variable and degrades gracefully when color is not appropriate. Package information is presented in a structured, readable format rather than raw key-value pairs.

For scripting, the --json flag switches the entire output to JSONL format, where each line is a self-contained JSON object. This means you can pipe any pkgcli command directly into jq and work with structured data without parsing text. The JSONL format, rather than a single JSON array, allows for streaming output and easier integration with Unix pipelines.

The defaults were also updated to reflect contemporary expectations. Metadata cache age and automatic cleanup of unused dependencies, for example, are now enabled by default. These are small changes, but they align pkgcli with what users have come to expect from modern package managers.

The Naming Question

There is a small but instructive story in the tool's name. It was originally called pkgctl, following the naming pattern established by other cross-distribution tools. However, that name was already claimed by an Arch Linux-specific distribution development tool. Rather than create confusion or force users to distinguish between two tools with the same name, the decision was made to rename it to pkgcli. It is a pragmatic choice that prioritizes clarity over consistency with a naming convention.

What This Means for the Ecosystem

The introduction of pkgcli is not a dramatic shift in the Linux package management landscape, and that is precisely the point. PackageKit was always designed as stable infrastructure, something that should work quietly and reliably while higher-level tools build on top of it. What pkgcli provides is a tool that respects that philosophy while making the daemon actually accessible to the people who need to interact with it directly.

For distributions that rely on PackageKit for automatic updates and GUI software management, pkgcli offers a proper command-line counterpart. For developers and maintainers working on PackageKit itself, it provides the testing and debugging interface that pkcon never fully was. And for users who want to script package operations without tying themselves to a specific package manager's CLI, it offers a structured, JSON-capable interface that speaks the language of modern tooling.

pkgcli has been available since PackageKit 1.3.4, included by default in the build. If your distribution ships a recent enough version of PackageKit, it is already available on your system. The project welcomes feedback, bug reports, and patches, as any well-maintained open source project should.