Prototype FreeBSD package definitions
This commit is contained in:
114
docs/PROGRESS.md
114
docs/PROGRESS.md
@@ -1152,3 +1152,117 @@ Next recommended step:
|
||||
2. carry forward the concrete real-checkout runtime blocker for later integration work:
|
||||
- investigate the `leave-on-EPIPE` failure in `./pre-inst-env guix --version`
|
||||
3. continue using `/frx/store` rather than `/gnu/store` for future FreeBSD store experiments when the prototype work needs a persistent store root
|
||||
|
||||
## 2026-04-01 — Phase 3.2 completed: FreeBSD system package-definition prototype and profile validation added
|
||||
|
||||
Completed work:
|
||||
|
||||
- added a Guix-style FreeBSD system package-definition prototype module:
|
||||
- `modules/fruix/packages/freebsd.scm`
|
||||
- added a Scheme harness to materialize those package definitions into store-like outputs and a merged profile:
|
||||
- `tests/packages/freebsd-package-profile-prototype.scm`
|
||||
- added a shell wrapper for that harness:
|
||||
- `tests/packages/run-freebsd-package-profile-prototype.sh`
|
||||
- installed the missing host shell dependency needed to satisfy the requested package set:
|
||||
- `bash`
|
||||
- wrote the Phase 3.2 report:
|
||||
- `docs/reports/phase3-freebsd-package-definitions.md`
|
||||
- ran the profile prototype successfully and captured metadata under:
|
||||
- `/tmp/freebsd-package-profile-prototype-metadata.txt`
|
||||
|
||||
Important findings:
|
||||
|
||||
- the prototype now defines a minimal FreeBSD core package set covering the categories requested by Phase 3.2:
|
||||
- kernel
|
||||
- kernel headers
|
||||
- libc
|
||||
- userland utilities
|
||||
- development tools (`clang`, `make`, autotools)
|
||||
- minimum system libraries (`openssl`, `zlib`)
|
||||
- shells (`sh`, `bash`)
|
||||
- the current package-definition layer uses an explicit Guix-like record shape with fields for:
|
||||
- name
|
||||
- version
|
||||
- build system
|
||||
- inputs
|
||||
- synopsis/description/home-page/license
|
||||
- install plan
|
||||
- explicit dependency relationships are now encoded and resolved recursively during materialization, including examples such as:
|
||||
- `freebsd-libc` -> `freebsd-kernel-headers`
|
||||
- `freebsd-userland` -> `freebsd-libc`, `freebsd-sh`
|
||||
- `freebsd-clang-toolchain` -> `freebsd-libc`, `freebsd-kernel-headers`, `freebsd-sh`
|
||||
- `freebsd-autotools` -> `freebsd-gmake`, `freebsd-bash`, `freebsd-libc`
|
||||
- the harness successfully materialized:
|
||||
- `11` core package outputs
|
||||
into a store-like directory tree under the work directory
|
||||
- it then merged those outputs into a development profile and validated that the profile contains working:
|
||||
- `bash`
|
||||
- `make`
|
||||
- `autoconf`
|
||||
- `cc`
|
||||
- kernel image path
|
||||
- kernel-header path
|
||||
- core shared-library paths
|
||||
- the generated profile compiled and ran a C test program successfully, with observed output:
|
||||
- `hello-from-freebsd-profile`
|
||||
- for executables installed under `bin/`, the prototype uses wrappers that `exec` the host tool by absolute path; this preserved correct behavior for prefix-sensitive tools such as `autoconf`
|
||||
|
||||
Current assessment:
|
||||
|
||||
- Phase 3.2 is now satisfied on the current prototype track
|
||||
- Phase 3 as a whole is now completed on the current FreeBSD amd64 path because both:
|
||||
- adapted GNU build-system execution, and
|
||||
- minimal FreeBSD system package-definition/profile validation
|
||||
have been demonstrated successfully
|
||||
- the next remaining project milestone is now Phase 4, centered on Shepherd rather than package-building foundations
|
||||
|
||||
## 2026-04-01 — Phase 3 completed on the current FreeBSD prototype track
|
||||
|
||||
Phase 3 is now considered complete for the active FreeBSD amd64 prototype path.
|
||||
|
||||
Why this milestone is satisfied:
|
||||
|
||||
- **Phase 3.1** success criteria were met on the prototype track:
|
||||
- a reusable FreeBSD adaptation layer for GNU builder phases was added
|
||||
- five representative GNU packages built successfully through that adapted runner
|
||||
- the resulting binaries executed correctly on the host
|
||||
- **Phase 3.2** success criteria were met on the prototype track:
|
||||
- a minimal FreeBSD system package-definition layer was added
|
||||
- explicit dependency relationships were modeled and resolved
|
||||
- the package outputs installed into a merged profile successfully
|
||||
- the generated profile was validated by compiling and running a test program with the staged toolchain
|
||||
|
||||
Important scope note:
|
||||
|
||||
- this completes the **build-system adaptation milestone** in prototype form, not the full Guix package-lowering/daemon integration path
|
||||
- the earlier concrete upstream/runtime blocker still exists for later integration work:
|
||||
- `./pre-inst-env guix --version` fails with `Wrong type to apply: #<syntax-transformer leave-on-EPIPE>`
|
||||
- however, that blocker no longer prevents Phase 4 work because the core build-system and package-definition assumptions have now been validated independently
|
||||
|
||||
Recent commits:
|
||||
|
||||
- `e380e88` — `Add FreeBSD Guile verification harness`
|
||||
- `cd721b1` — `Update progress after Guile verification`
|
||||
- `27916cb` — `Diagnose Guile subprocess crash on FreeBSD`
|
||||
- `02f7a7f` — `Validate local Guile fix on FreeBSD`
|
||||
- `4aebea4` — `Add native GNU Hello FreeBSD build harness`
|
||||
- `c944cdb` — `Validate Guix builder phases on FreeBSD`
|
||||
- `0a2e48e` — `Validate GNU which builder phases on FreeBSD`
|
||||
- `245a47d` — `Document gaps to real Guix FreeBSD builds`
|
||||
- `d62e9b0` — `Investigate Guix derivation generation on FreeBSD`
|
||||
- `c0a85ed` — `Build local Guile-GnuTLS on FreeBSD`
|
||||
- `15b9037` — `Build local Guile-Git on FreeBSD`
|
||||
- `47d31e8` — `Build local Guile-JSON on FreeBSD`
|
||||
- `d82195b` — `Advance Guix checkout on FreeBSD`
|
||||
- `9bf3d30` — `Document FreeBSD syscall mapping`
|
||||
- `7621798` — `Prototype FreeBSD jail build isolation`
|
||||
- `d65b2af` — `Prototype FreeBSD build user isolation`
|
||||
- `e404e2e` — `Prototype FreeBSD store management`
|
||||
- `eb0d77c` — `Adapt GNU build phases for FreeBSD`
|
||||
|
||||
Next recommended step:
|
||||
|
||||
1. begin Phase 4.1 by validating whether Shepherd itself now builds and runs as a regular service on FreeBSD with the fixed local Guile path
|
||||
2. carry forward the separate real-checkout runtime blocker for later integration work:
|
||||
- investigate the `leave-on-EPIPE` failure in `./pre-inst-env guix --version`
|
||||
3. continue using `/frx/store` rather than `/gnu/store` for future FreeBSD integration experiments when a persistent store root is required
|
||||
|
||||
165
docs/reports/phase3-freebsd-package-definitions.md
Normal file
165
docs/reports/phase3-freebsd-package-definitions.md
Normal file
@@ -0,0 +1,165 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user