Linxira's software ecosystem has several entry points: the installer's software selection, the Welcome screen's recommendations, and graphical package management. If each entry point maintained its own software list, drift would be inevitable — something in the installer but missing from Welcome; something recommended by Welcome but absent from the software manager. The catalog is the architecture that answers this: every entry point consumes the same reviewed metadata. This article covers the relationship between catalog v2 and v3, and the "GUI plans, backend executes" design.
A useful framing before the technical details: for users, the software ecosystem is not "a package manager plus some lists" — it is the most visible surface of the whole distribution. It is what they choose at install, what they browse after install, and what determines whether the machine fits their work. If that surface is inconsistent, the distribution feels broken in a way no feature list can compensate for; the catalog is the load-bearing piece that keeps the surface coherent.
A distribution touches its software ecosystem in more ways than it looks: what to install during setup, what the welcome screen recommends afterwards, what the graphical software manager displays, how curated applications are categorized. If each surface keeps its own software list, the consequence is certain: data inconsistency. The same application present in one list and absent from another; the same category called one thing here and another thing there; updating one list while missing another.
The subtler problem is trust inconsistency: one list is reviewed and another is not, so users cannot tell what "officially recommended" even means. The starting point of the catalog: converge "which applications are available, what they are, and why they are recommended" into a single dataset, have every entry point read that same dataset, and eliminate drift by structure.
A concrete drift example: suppose the installer maintains its own list for the "scientific computing" category and Welcome maintains another. An application gets replaced by a new version, another is removed over a license problem — one list updated, the other missed, and users see it in the installer but not in Welcome. Worse, nobody notices it is a bug, because both lists look "complete enough". Shared data eliminates this whole class of error structurally: change it once, it takes effect everywhere. The maintenance burden shrinks with it: one list to review and update instead of several that must be kept in sync by hand.
The catalog also answers a maintainer-side question: who decides what is recommended? With a single reviewed dataset, the answer is explicit — one review process, one place where applications enter or leave, one audit trail. New applications are added by being reviewed into the catalog; removals happen by being reviewed out of it. "Recommended" is a property of the catalog, not a property of whichever page happened to list an application.
catalog v2 is the carrier of reviewed configuration: the recommendation links of Welcome, Calamares (the installer), Config Hub, and Shelly all read the same reviewed catalog v2. During install you pick optional reviewed configurations from catalog v2 and create your user account; after install, the Welcome screen and software manager recommendations come from the same source.
v2's role is "compatibility retention": it keeps working as the shared data source for the installer and recommendation links, and is not discarded when v3 arrives. For existing users, v2 behaves exactly as before; it is retained so that the install flow and recommendation chain do not have to migrate along with the architecture upgrade.
What "reviewed configuration" means in the install scenario: what the installer shows users is not a raw list of package names but reviewed, described, checkable configuration items — when a user picks "scientific computing" or "development tools", they are selecting a reviewed set of software rather than judging each package individually. The same dataset feeds Welcome's and Shelly's recommendation links, so what you see at install time matches what you see after install.
catalog v3 is the new application / component / capability graph, made of four entity types: desktops, applications, components, and bundles. It is not merely "an application list" — it is structured data describing the relationships between applications, components, and capabilities: which category an application belongs to, which components it depends on, which bundle it ships in, all expressed in the same graph.
Review covers three dimensions: license (can it be distributed with Linxira), source (official repository or third party, reproducible or not), and availability (actually usable on the current architecture and baseline). Reviewed applications are organized into 14 categories, 93 in total; the external ecosystem (AUR and similar) is off by default and must be enabled explicitly. The direct user-facing effect: the 93 applications on the software ecosystem page and the categories in the applications documentation are all backed by the same v3 data.
The division of labor among the four entity types is worth expanding: desktops describe the selectable desktop environments and their reviewed configurations; applications are what end users see, with their categories; components are the capability packages, runtimes, and toolchains behind applications (not necessarily "applications" themselves, but the prerequisite for applications to work); bundles combine applications and components into scenario-oriented sets — a "scientific computing" bundle can carry all the components it depends on at once. Category trees, component dependencies, and scenario bundles all live in this one graph instead of scattered hardcoded lists.
The catalog is only metadata — it installs nothing. What actually touches the system is the backend, and the responsibilities of GUI and backend are strictly separated: interfaces display and plan; system modifications are executed by controlled backends as deterministic transactions.
This principle shows up differently in each tool: Shelly (the post-install graphical software manager) only performs approved package operations and never participates in installer transactions — installer transactions belong to Calamares and its companion backends, and the two never cross; Package Center (curated application install) splits installation into a plan / confirm / apply three-step transaction — the package operations to be executed are planned first, and only applied after the user confirms; Component Manager (component selection) expresses choices as a three-state tree (required / recommended / optional) and only installs — it does not support removal, pinning down the boundary between "planning" and "execution".
Underneath sits the linxira-components backend: a catalog-bound pacman transaction planning and receipt backend — deterministic plans, SHA-256 canonical JSON digests, root-only pacman, persistent receipts, exposed over the D-Bus service org.linxira.Components1. GUIs never touch pacman directly; they submit plans to the backend, which executes deterministically and leaves an auditable record.
"Deterministic" carries a concrete technical meaning here: the same catalog and the same choices always plan the same transaction, and the produced digest is recomputable and comparable. Persistent receipts mean the system keeps a machine-readable record of "what was installed and according to what plan" — not only can users look it up, subsequent tools can build incremental operations on it instead of guessing the system state again.
What the plan / confirm / apply transaction feels like to a user is worth stating plainly: installing from Package Center first shows you a plan — the exact package operations that will run — then asks for confirmation, and only then applies. The GUI never claims "I installed it" while the backend is still deciding; the user always sees the plan before anything touches the system. That single UX decision is the visible face of the whole read-only / planning model.
"Reviewed catalog" and "stuff everything into the ISO" are opposite approaches. The temptation of stuffing the ISO is intuitive: the more preinstalled, the stronger the "works out of the box" feeling. But the cost is real: ISO bloat, a larger maintenance surface, long-term responsibility for every preinstalled package's license and source — and preinstalled software users cannot remove becomes a burden.
The reviewed-catalog trade-off is the reverse: only a reviewed subset is installed by default, everything else is installed on demand through the catalog; unreviewed AUR recipes are never presented as official software — they may exist and may be explicitly enabled by the user, but they never appear in official recommendations. The result: the official software list is always "the list we reviewed and can stand behind", not "the list of everything installable on the internet".
This trade-off gives the phrase "official software" its meaning back. More details on the configuration side live in the Config Hub documentation; the catalog's application-side data is in software ecosystem and applications.
Why default the external ecosystem off instead of on? Because the cost of "open" is not what users install, but what users trust — an open-by-default ecosystem dilutes the meaning of "officially recommended" and blurs the line between reviewed and unreviewed sources. Default-off plus explicit opt-in preserves freedom of choice while keeping the official list semantically clean: users who need AUR can enable it with one command, and users who do not will never see unreviewed recipes in the recommendations.