cpak v2 is here

I started cpak in September 2023 because distributing a Linux application had become a choice between rebuilding it around someone else's runtime or asking users to assemble the right pieces themselves. OCI already had a mature way to publish content-addressed images, but the desktop needed its own package identity, update model and direct access to the Linux services applications already know how to use.

The result is a single Go binary which installs an application from its real Git repository, resolves its OCI image and applies a manifest that can be read before anything runs. The same manifest describes desktop entries, dependencies, devices and the host operations the application may request. There is no daemon keeping a second container stack alive behind it.

Packages that keep their origin

A cpak package is still a Git repository. It may follow a branch, a release or one immutable commit, while the OCI digest records the exact image installed on the machine. Updates are staged before they become active and the previous installation remains available for rollback. The Store does not replace that origin. It makes those repositories discoverable and shows what they contain.

Storage follows the same rule. Equal OCI layers are downloaded once and shared by every package that uses them. DaBaDee then catches equal files that arrived through different layer layouts, so duplicated content can still share the same bytes on disk. Applications keep their writable data separate, but they do not each need a private copy of the same operating system base.

One click without hiding the package

Every application page in the Store can now produce a signed cpak installer. The installer shows the application, its origin and its requested permissions before downloading the image. It also contains the matching cpak binary, so the first application does not begin with a terminal guide or a distribution-specific bootstrap package.

This does not turn cpak into a central repository. Package manifests and images remain in the publisher's repositories, releases stay connected to their source and the command used by the installer can be inspected or copied from the Store.

Bottles is the first real test

Bottles 66 is the first large project to publish cpak as an official package alongside Flatpak. That matters because Bottles is not a convenient demo. It needs graphics drivers, Wine runners, UMU, nested packages, desktop entries and persistent application data to agree with each other. If cpak can carry Bottles without asking it to impersonate another package format, the runtime is being tested where its design actually matters.

Less than 24 hours after the release, that test already produced the first external bug report. Issue #20 found that a valid Landlock ABI on NixOS could still reject a filesystem rule for a device node. The report included a complete reproduction, the host checks and the exact point where Firefox stopped before startup. This is exactly why cpak is public now: real machines find assumptions that a development environment cannot.

The work starts here

v2 gives cpak a stable manifest, signed installers and enough runtime surface to package real applications. The Store already carries browsers, editors, creative tools, games and development SDKs, but the next useful result will come from running them across more distributions, desktop sessions and hardware.

Install an application, read the permissions before accepting them and report what the runtime gets wrong on your machine. Bottles and Firefox are good places to start. A clean bug report is more valuable right now than pretending every Linux configuration has already been covered.