libpkgapply

libpkgapply is the semantic application authority for one accepted package operation plan.

It validates immutable application requests, binds one exact target context and caller-held mutation lease, revalidates planning preconditions, derives the ordered effect schedule, records write-ahead intent and completion, classifies recovery obligations, validates final observations, and seals completed or non-completed application evidence.

The core owns:

• application attempts and backend identities;
• immutable package application requests;
• target contexts and exact lease-bound state projections retained by durable application journals;
• precondition validation and deterministic effect schedules;
• rejected, active, recovery, and final-observation evidence models;
• append-only journal declaration/step/cursor semantics, owner-derived restart views, completed-evidence codecs, and application-receipt codecs;
• restart admission and replay policy; and
• abstract backend, transaction, observation, staging, capture, publication, and mutation contracts.

The core never opens host paths, acquires an OS lock, stages bytes in a filesystem, mutates a target namespace, or chooses persistence directories. Those mechanisms are supplied by an independent backend product.

libpkgapply-posix owns the extracted descriptor-anchored POSIX implementation formerly shipped in this repository. It implements target observation, target mutation leases, private payload and capture stores, rejected-object publication, journal storage, completed-evidence storage, active namespace mutation and recovery, and concrete backend composition. The provider may retain subordinate physical attempt stores, but it does not own a second semantic restart checkpoint. Journal storage and mutation transactions remain separate objects even when one mechanism product implements both.

libpkgbuild-image + libpkgsource-plan + libpkgplan
 |
 v
 libpkgbuild-plan
 planner-ready built package authority
 |
 v
 libpkgapply
 semantic request, schedule, journal, recovery, evidence
 |
 v
 application_backend contract
 |
 +----------+----------+
 | |
 v v
 libpkgapply-posix another mechanism provider

Installed state publication is not part of application. libpkgstate-apply consumes completed application evidence and constructs state publication requests after application returns.

The generation-4 development line separates semantic journal persistence from physical mutation transactions. apply() receives an explicit application_journal_store; fresh execution publishes one immutable declaration and then one immutable step plus bounded cursor advance per semantic transition. Restart is addressed by the same store and exact declaration identity. The mutation backend no longer publishes complete journal snapshots or synchronizes the journal durability domain.

This is SONAME 4 / public API generation 4. The generation change is deliberate: the transaction virtual interface and all package-manager-facing apply/restart entry points changed. No generation-3 compatibility shim is retained.

Restart now derives an ephemeral application_restart_view from the retained owner declaration and exact step chain before reopening the backend. The view has no durable codec. Backend reopen consumes it only to revalidate subordinate physical evidence; provider-authored restart checkpoints are not part of the core generation-4 contract.

Release 3.0 separates the already distinct POSIX product and corrects application admission against the current authority graph. Installed headers require:

• libpkgbuild-plan >= 1.1.0, < 2.0.0; and
• libpkgplan >= 0.3.0, < 1.0.0.

Build/image agreement and source-to-planner projection are upstream statements retained through libpkgbuild-plan; they are not reconstructed by libpkgapply. Likewise, an application journal retains the exact admitted lease-bound state-projection body. Restart may validate current state under a new lease, but it never reconstructs the historical projection from that current observation. OpenSSL libcrypto is the only private pkg-config requirement. Transitive authority libraries remain legitimate implementation ELF needs where opaque accessors are used and enter consumer flags only for static linkage.

The 3.0 core is SONAME 3 / public API generation 3. The generation advances because incoming package authority now admits the opaque libpkgbuild-plan projection rather than the published 2.x build-result/image pair. The old ABI is not carried as a compatibility shim.

Fallback subprojects are intentionally unsupported. Shared and static closures must be built separately.

meson setup build \
 -Ddefault_library=shared \
 -Dlink_mode=shared \
 -Dwerror=true
meson compile -C build
meson test -C build --print-errorlogs

See DESIGN.md, TESTING.md, docs/integration.md, docs/abi.md, and MAINTAINING.md before changing the boundary.

GPL-3.0-or-later. See COPYING and COPYRIGHT.