The platform under every official cpak

cpak does not require one distribution or one build system. A package can start from any OCI image that supplies the ABI expected by its application. The official catalogue uses a controlled Ubuntu snapshot because it gives package recipes APT without making each application carry a complete distribution of its own. The resulting foundation is flattened into one layer after package indexes, downloaded archives, manuals and build-only files have been removed.

The old desktop base did too much

I split the platform around the libraries applications actually use. A GTK 3 package starts from gtk3; WebKitGTK 4.1 adds one layer above it. GTK 4, libadwaita and WebKitGTK 6 have their own branch, while multilib software keeps a separate graphics path. The complete desktop image remains available for software that really crosses those boundaries and for existing recipes that still use it.

foundation
└── mesa64
    ├── gtk3
    │   └── webkitgtk
    ├── gtk4
    │   └── adwaita
    │       └── webkitgtk6
    └── mesa-multilib

A GTK 3 update no longer invalidates the GTK 4 or multilib branches, and an application update keeps every unchanged platform layer already in the local store.

Your locale is downloaded once

Application translation catalogs still belong to each application. Compiled system locale data does not. cpak 2.4.1 reads the locale used by the host and attaches only that data from the matching locales image. The layer is downloaded once and reused by every compatible package. Application overrides still win, and other publishers opt in by declaring their own locale image.

Versioned foundations, normal package reviews

main follows the newest platform build, ubuntu-26.04 follows that Ubuntu release and ubuntu-26.04.20260814.4 identifies one exact state. Official packages follow the release tag, but a new platform never appears inside them silently: each package is rebuilt and checked by its own CI first.

For this rollout, every package listed in the official Store is being rebuilt on the new bases. SDKs and Wine-based packages follow the same chain, so the catalogue moves to one platform generation instead of updating piece by piece.

Package maintainers only need to choose the smallest matching platform, keep build tools outside the final stage and pull the current platform digest during CI. The complete platform table, tag policy, SDK equivalents and recipe examples are in the OCI image guide. The earlier catalogue diagnosis contains the download and installed-size measurements behind this work.