fruix/docs/reports/phase15-self-hosting-decision-freebsd.md

Phase 15.3: decision on self-hosted FreeBSD base builds

Date: 2026-04-03

Question

After Phases 13 through 15, should Fruix immediately pursue self-hosted FreeBSD base builds inside a Fruix-managed guest, or should it continue using the host builder while tightening source/reproducibility boundaries?

Current evidence

What is now already true:

• Fruix builds native FreeBSD base artifacts from /usr/src into /frx/store
• Fruix has validated a host-base-free boot/runtime path composed from:
  • freebsd-native-kernel
  • freebsd-native-bootloader
  • freebsd-native-runtime
• that path boots locally under QEMU/UEFI and on the approved real XCP-ng VM/VDI
• the FreeBSD base is now an explicit declarative system input through freebsd-base
• Fruix can keep distinct declared base versions side by side in /frx/store
• Fruix can roll forward to a candidate base declaration and roll back to the earlier closure without mutating it in place

So the main Guix-inspired value proposition is already present at the system-deployment layer:

• declarative system descriptions
• content-addressed outputs
• side-by-side versions
• rollback-friendly closures

What is still not strong enough for self-hosting to be the best next step

1. Source acquisition is still too host-local

The native base path still depends on the host's local /usr/src tree as the source of truth.

That means the next reproducibility win is not "build inside the guest" first; it is "make the source tree selection/acquisition more explicit and reproducible" first.

2. The host-built path is already validated and useful

The current host-built native base flow is not hypothetical anymore. It has already proven:

• native artifacts in /frx/store
• host-base-free boot/runtime composition
• side-by-side closures
• rollback behavior

That makes it the productive path to continue refining.

3. Self-hosting would currently mix several problems at once

Jumping to guest self-hosting now would combine:

• source acquisition/reproducibility questions
• toolchain/profile maturity questions
• build-environment modeling questions
• large build-resource/runtime questions inside the guest
• deployment/debugging questions

That would make failure analysis worse just after the project finally obtained a clean validated deployment path.

4. Platform constraints still argue for caution

Current operator/environment constraints still matter:

• local bhyve remains blocked under Xen due to missing nested VT-x exposure
• real VM validation still reuses a single approved XCP-ng VM/VDI pair
• XCP-ng storage permissions still prevent creating fresh VDIs on demand

Those constraints do not block the current host-built native-base path, but they do make an early self-hosting pivot less attractive.

Decision

Decision: do not pursue self-hosted FreeBSD base builds as the next immediate milestone.

The near-term direction should remain:

1. continue building native FreeBSD base artifacts on the host
2. keep storing them in /frx/store
3. improve declarative source-tree/version selection and provenance
4. tighten reproducibility around source inputs and build parameters
5. only revisit self-hosting after those pieces are stronger

Why this is the right decision now

This preserves the important architectural win already achieved:

• Fruix, not ad hoc host copying, now defines the deployed FreeBSD base through declared store artifacts

It also follows the same spirit as Guix generation/rollback semantics: the crucial user-facing property is not where the build happened first, but that the result is declarative, content-addressed, side-by-side, and rollback-friendly.

At this point Fruix already has those properties for the FreeBSD base path.

Conditions for revisiting self-hosting later

Self-hosted base builds should be reconsidered only after at least most of the following are true:

• Fruix can select or acquire distinct FreeBSD source trees more reproducibly than a single ambient /usr/src
• the native development/toolchain side is modeled cleanly enough for a Fruix-managed build environment
• operator/deployment tooling can handle larger iterative validation loops without excessive friction
• there is a concrete benefit to guest-side base builds beyond what host-built store artifacts already provide

Recommended next focus after Phase 15

The next work should likely focus on improving the declared source/reproducibility boundary around the now-working native base path, rather than on guest self-hosting.

A good next phase would be centered on things like:

• declarative source-tree selection/acquisition for the FreeBSD base
• stronger provenance for declared source inputs
• cleaner rebuilds across multiple source trees or revisions
• continued refinement of deployment/generation management around the existing store-based base artifacts

Result

Phase 15.3 is complete.

The project now has an evidence-based decision:

• near-term path: host-built native FreeBSD base artifacts in /frx/store
• not yet: self-hosted FreeBSD base builds inside the Fruix guest