fruix/docs/reports/phase1-guix-derivation-generation-investigation.md

Phase 1.2 follow-up: derivation-generation investigation from a Guix checkout on FreeBSD

Date: 2026-04-01

Summary

This step investigated how far FreeBSD can get toward a real Guix package/derivation build from a Guix source checkout, and captured the first concrete failure boundary.

Added harness:

• tests/guix/run-derivation-generation-investigation.sh

Per operator instruction, all store-related configuration in this investigation used:

• store directory: /frx/store

and, to keep the experimental Guix state alongside that store prefix, the configure attempts also used:

• local state directory: /frx/var
• sysconf directory: /frx/etc

Goal

The immediate goal was not to complete a full build, but to answer a narrower question left open by the previous reports:

What is the first actual blocker when trying to move from FreeBSD builder-phase prototypes toward a real Guix checkout capable of derivation generation?

What was attempted

A disposable shared clone of ~/repos/guix was created under /tmp, then:

1. ./bootstrap was run successfully
2. configure was run without --with-courage
3. configure was run again with --with-courage

The harness used the previously validated fixed local Guile build:

• /tmp/guile-freebsd-validate-install/bin/guile

Reproduction command

METADATA_OUT=/tmp/guix-derivation-investigation.txt \
  ./tests/guix/run-derivation-generation-investigation.sh

Result

The investigation did not reach derivation generation yet.

Instead, it identified two earlier gating failures.

Finding 1: unsupported-platform gate in configure

Without --with-courage, configuration fails immediately on FreeBSD with:

checking for the Guix system type... x86_64-freebsd15.0
configure: error: `x86_64-freebsd15.0' is not a supported platform.

This confirms that a stock Guix checkout currently refuses to configure on FreeBSD before any daemon/store/derivation logic is exercised.

Finding 2: missing Guile (gnutls) bindings after bypassing the platform gate

When configure is re-run with --with-courage, it gets past the unsupported-platform gate but then stops with:

configure: error: The Guile bindings of GnuTLS are missing; please install them.

A direct check with the same local fixed Guile build confirmed that:

(use-modules (gnutls))

currently fails on this host with:

no code for module (gnutls)

Interpretation

This is useful because it pinpoints the current failure boundary more precisely than before.

The first blockers toward a real Guix checkout capable of derivation generation on FreeBSD are currently:

1. a deliberate unsupported-platform configure gate
2. a missing mandatory Guile (gnutls) module dependency needed by the checkout configuration

This means the project is still blocked before:

• pre-inst-env generation usable for Guix commands
• package -> bag lowering in a live Guix checkout
• bag -> derivation lowering
• store daemon connection
• /frx/store population or management

What this does and does not prove

This step proves:

• a Guix checkout can be bootstrapped successfully on FreeBSD
• Guix's configure logic explicitly rejects FreeBSD unless --with-courage is used
• after bypassing that gate, the next immediate blocker is missing Guile GnuTLS bindings

This step does not yet prove:

• whether derivation generation itself works on FreeBSD
• whether daemon connectivity works
• whether /frx/store can be initialized and used successfully
• whether the next blocker after GnuTLS would be store-related or daemon-related

Notes on /frx

No actual /frx/store was created or populated in this step because the checkout did not get far enough.

However, this investigation establishes the intended experimental store path for subsequent work:

• /frx/store

rather than Guix's usual /gnu/store.

Recommended next step

The most direct next step is to obtain working Guile (gnutls) bindings compatible with the fixed local Guile build, then re-run this derivation-generation investigation.

That should reveal the next actual failure boundary, which is likely to be one of:

• generated checkout/runtime module issues
• derivation emission
• daemon connectivity
• daemon-side assumptions about the store or build environment