Files
fruix/docs/reports/phase3-freebsd-package-definitions.md

166 lines
6.0 KiB
Markdown

# Phase 3.2: FreeBSD system package-definition prototype and profile validation
Date: 2026-04-01
## Summary
This step adds a minimal FreeBSD system package-definition prototype and validates that the resulting packages can be materialized into store-like outputs and installed into a profile that is usable for development tasks.
Added files:
- `modules/fruix/packages/freebsd.scm`
- `tests/packages/freebsd-package-profile-prototype.scm`
- `tests/packages/run-freebsd-package-profile-prototype.sh`
The package-definition module is intentionally a **Guix-style prototype layer** rather than a fully integrated Guix package collection, because full host-side package lowering and daemon integration are still blocked upstream on this FreeBSD path. Even so, it provides explicit package metadata, dependency relationships, build-system tags, install plans, and a profile-validation harness.
## Prototype package set
The module currently defines the following minimal core set:
- `freebsd-kernel`
- `freebsd-kernel-headers`
- `freebsd-libc`
- `freebsd-userland`
- `freebsd-clang-toolchain`
- `freebsd-gmake`
- `freebsd-autotools`
- `freebsd-openssl`
- `freebsd-zlib`
- `freebsd-sh`
- `freebsd-bash`
These cover the categories requested by Phase 3.2:
- FreeBSD kernel and kernel headers
- FreeBSD libc
- FreeBSD userland utilities
- development tools (`clang`, `make`, autotools)
- minimum system libraries (`openssl`, `zlib`)
- a basic shell (`sh`, `bash`)
## Definition style
The module uses a Guix-like package record shape with explicit fields for:
- name
- version
- build system
- inputs
- home page
- synopsis
- description
- license
- install plan
This keeps the structure close to Guix package-definition practice even though the current harness interprets the definitions itself rather than asking a working Guix daemon to lower them.
## Materialization and profile harness
Run command:
```sh
METADATA_OUT=/tmp/freebsd-package-profile-prototype-metadata.txt \
./tests/packages/run-freebsd-package-profile-prototype.sh
```
What the harness does:
1. loads the prototype package definitions
2. recursively materializes each package into a store-like directory under the harness work tree
3. records dependency references between the package outputs
4. assembles a merged profile from the selected package set
5. validates the resulting profile by checking for:
- shell availability
- compiler availability
- make availability
- autotools availability
- kernel image presence
- kernel-header presence
- core library presence
6. compiles and runs a small C program using tools from the generated profile
## Observed results
Observed metadata from the successful run included:
- `core_package_count=11`
- `profile_package_count=11`
- `bash_version=GNU bash, version 5.3.9...`
- `make_version=GNU Make 4.4.1`
- `autoconf_version=autoconf (GNU Autoconf) 2.72`
- `cc_version=FreeBSD clang version 19.1.7 ...`
- `hello_output=hello-from-freebsd-profile`
The validation program was compiled and run successfully from the generated profile, producing:
```text
hello-from-freebsd-profile
```
## Dependency relationships validated
The prototype explicitly records useful dependency edges, for example:
- `freebsd-libc` depends on `freebsd-kernel-headers`
- `freebsd-userland` depends on `freebsd-libc` and `freebsd-sh`
- `freebsd-clang-toolchain` depends on `freebsd-libc`, `freebsd-kernel-headers`, and `freebsd-sh`
- `freebsd-gmake` depends on `freebsd-sh` and `freebsd-libc`
- `freebsd-autotools` depends on `freebsd-gmake`, `freebsd-bash`, and `freebsd-libc`
- `freebsd-openssl` depends on `freebsd-libc`
- `freebsd-zlib` depends on `freebsd-libc`
- `freebsd-bash` depends on `freebsd-libc`
These dependencies are not merely documented; the harness resolves them recursively when materializing outputs and building the final profile.
## Important implementation notes
### 1. Executable entries are wrapped, not copied verbatim
For package entries installed under `bin/`, the harness creates small wrappers that `exec` the host tool by absolute path. This avoids breaking tools such as `autoconf` that expect their installed prefix layout or auxiliary data files to remain coherent.
### 2. Data trees are copied where profile-local structure matters
For items such as:
- kernel headers
- automake support files
- autoconf data
- libtool auxiliary data
whole directory trees are copied into the package outputs so that the generated profile has the expected on-disk structure.
### 3. This is a prototype package-definition layer, not final Guix integration
The current result demonstrates packaging shape and profile usability. It does **not** yet provide:
- real Guix `package` lowering on FreeBSD
- derivation generation from these package definitions
- daemon-backed builds into `/frx/store`
- real profile generation by `guix package`
Those remain later integration tasks.
## Why this satisfies Phase 3.2 on the prototype track
Phase 3.2 asked for a minimal FreeBSD package-definition set and validation that the packages build, relate correctly, and can be installed into profiles for practical use.
That goal is satisfied on the current prototype track because:
- the requested FreeBSD system-component categories are all represented
- explicit dependency relationships are encoded and resolved
- the package set materializes successfully into store-like outputs
- the outputs install into a merged profile successfully
- the resulting profile is practically usable for development validation, including compilation and execution of a test program using the staged toolchain
## Conclusion
Phase 3.2 is satisfied on the current FreeBSD prototype track:
- a minimal FreeBSD system package-definition layer now exists in-repo
- dependency relationships are explicit and validated
- profile-style installation works
- the generated profile is usable for at least a concrete C build/run validation
With both Phase 3.1 and Phase 3.2 complete, the project has now finished the build-system adaptation milestone on the current FreeBSD path.