system: validate host-initiated native base builds
This commit is contained in:
@@ -38,6 +38,10 @@ Fruix currently has:
|
||||
- `/run/current-system/development-profile`
|
||||
- `/run/current-development`
|
||||
- `/usr/local/bin/fruix-development-environment`
|
||||
- a validated host-initiated native base-build path inside a Fruix-managed guest via:
|
||||
- real XCP-ng boot of a development-enabled Fruix system
|
||||
- in-guest `buildworld` / `buildkernel`
|
||||
- staged `installworld` / `distribution` / `installkernel`
|
||||
|
||||
Validated boot modes still are:
|
||||
|
||||
@@ -50,37 +54,40 @@ The validated Phase 18 installation work currently uses:
|
||||
|
||||
## Latest completed achievement
|
||||
|
||||
### 2026-04-05 — Phase 20.1 completed
|
||||
### 2026-04-05 — Phase 20.2 completed
|
||||
|
||||
Fruix now has a validated real-VM path where a booted Fruix-managed FreeBSD system exposes a separate development environment for native base work without collapsing the runtime/development split.
|
||||
Fruix now has a validated intermediate path where the host still orchestrates the workflow, but real FreeBSD native base-build work runs inside a booted Fruix-managed FreeBSD guest.
|
||||
|
||||
Highlights:
|
||||
|
||||
- operating-system declarations now support:
|
||||
- `#:development-packages`
|
||||
- system closures can now carry a separate development profile at:
|
||||
- `/run/current-system/development-profile`
|
||||
- `/run/current-development`
|
||||
- opt-in systems now ship an in-guest helper at:
|
||||
- `/usr/local/bin/fruix-development-environment`
|
||||
- the validated Phase 20.1 guest path exposes:
|
||||
- native headers
|
||||
- `usr/share/mk` for `bsd.*.mk`
|
||||
- Clang toolchain commands such as `cc`, `c++`, `ar`, `ranlib`, and `nm`
|
||||
- the validated guest workflow now supports:
|
||||
- `eval "$(/usr/local/bin/fruix-development-environment)"`
|
||||
- direct compilation with the Fruix-provided toolchain
|
||||
- a simple `bsd.prog.mk` build on the running Fruix guest
|
||||
- development-enabled systems now expose canonical native-build compatibility links at:
|
||||
- `/usr/include -> /run/current-system/development-profile/usr/include`
|
||||
- `/usr/share/mk -> /run/current-system/development-profile/usr/share/mk`
|
||||
- media builder versions were bumped so booted images and future installed targets pick up that rootfs layout change
|
||||
- the validated guest build path now runs real FreeBSD native build steps inside the Fruix-managed guest:
|
||||
- `buildworld`
|
||||
- `buildkernel`
|
||||
- `installworld`
|
||||
- `distribution`
|
||||
- `installkernel`
|
||||
- staged install steps use:
|
||||
- `DB_FROM_SRC=yes`
|
||||
- so the staged install is driven by the declared source tree's account database rather than by the guest's minimal local `/etc` state
|
||||
- the validated result now includes staged native artifact outputs for:
|
||||
- kernel
|
||||
- bootloader slice
|
||||
- headers / `usr/share/mk`
|
||||
|
||||
Validation:
|
||||
|
||||
- `PASS phase20-development-environment-xcpng`
|
||||
- `PASS phase20-host-initiated-native-build-xcpng`
|
||||
|
||||
Reports:
|
||||
|
||||
- `docs/system-deployment-workflow.md`
|
||||
- `docs/GUIX_DIFFERENCES.md`
|
||||
- `docs/reports/phase20-development-environment-freebsd.md`
|
||||
- `docs/reports/phase20-host-initiated-native-builds-freebsd.md`
|
||||
|
||||
## Recent major milestones
|
||||
|
||||
@@ -106,6 +113,6 @@ Reports:
|
||||
|
||||
Per `docs/PLAN_4.md`, the next planned step is:
|
||||
|
||||
- **Phase 20.2** — run host-initiated native base builds inside a Fruix-managed environment
|
||||
- **Phase 20.3** — reassess and potentially prototype guest self-hosted base builds
|
||||
|
||||
Phase 20.1 is now complete: Fruix validates a separate in-system development environment for native FreeBSD base work on the approved real XCP-ng path.
|
||||
Phase 20.2 is now complete: Fruix validates host-initiated native FreeBSD base builds running inside the approved real XCP-ng Fruix guest path.
|
||||
|
||||
Reference in New Issue
Block a user