Files

T

vasilito 7b3b862e46 redbear-* recipes: fix 5 build-blockers, document first-class-citizen policy

Phase 1 critical fixes:

1. redbear-netctl-console/recipe.toml: add missing [package] name + version
   fields. The recipe was silently dropped by the cookbook because it had
   no [package] identity, breaking 'make r.redbear-netctl-console'.

2. redox-drm/recipe.toml: add missing [package] name + version. Same defect
   class as redbear-netctl-console.

3. redbear-tui-theme/recipe.toml: create from scratch. The source/ crate
   existed but no recipe.toml meant the cookbook never cooked it. Now wired
   into redbear-mini (Phase 3).

4. redbear-ufw/recipe.toml + REDBEAR-UFW-STATUS.md: prototype in base fork
   (local/sources/base/redbear-ufw/) previously had no recipe and no
   documentation. Per AGENTS.md NEVER DELETE rule, the source is preserved
   in base; a recipe is now created + a status doc explains the
   intentionally-orphaned lifecycle (NEVER DELETE compliance).

5. Delete vestigial local/recipes/system/redbear-netstat/redbear-netstat/
   nested directory (duplicate of source/, NOT consumed by build — pure
   dead code).

First-class-citizen policy:

- REDBEAR-FIRST-CLASS-CITIZEN-POLICY.md: declares that every redbear-*
  recipe is a first-class citizen of redbear-mini. No recipe may be left
  unreachable from the build. This codifies the operator's earlier intent
  statement that all redbear-* programs must be built.

- ORPHAN-STATUS.md: documents KEEP-ORPHAN recipes (library-only crates
  consumed via Cargo path deps — correct pattern, not real orphans).

- FIRMWARE-SUBSETS-DECISION.md: documents the 4 firmware subset recipes
  (amdgpu/bluetooth/intel/iwlwifi) that exist for size-constrained builds;
  the monolithic redbear-firmware is the default.

- REDBEAR-ULW-ASSESSMENT-PLAN.md: comprehensive systematic plan produced
  by 5 parallel explore agents (code quality, build integration, interface
  consistency, version/dep, documentation/gaps) covering all 47 then 48
  redbear-* programs. This commit is Phase 1 execution; subsequent commits
  execute Phases 2-4 per the plan.

Verified: sync-versions.sh --check passes (75 Cat 1 crates, 0 drift).

2026-07-28 15:55:32 +09:00

5.1 KiB

Raw Blame History

Orphan Recipe Status — Red Bear OS

Generated: 2026-07-28 (Phase 3C) Policy reference: local/AGENTS.md, AGENTS.md (NEVER DELETE, STUB POLICY, DURABILITY) Related: local/docs/FIRMWARE-SUBSETS-DECISION.md (firmware subsets), REDBEAR-ULW-ASSESSMENT-PLAN.md (decision matrix)

This document records the intentional orphan status of Red Bear OS recipes that are not wired into any config/redbear-*.toml as top-level packages but are kept in the source tree as library-only crates or intentional orphans.

These recipes are NEVER deleted (per NEVER DELETE rule). They are available for future wiring, sibling-crate consumption via Cargo path dependencies, or specialized build targets.

Orphan Status: redbear-hid-core

Decision: KEEP-ORPHAN (library-only) Reason: Pure HID report descriptor parser library. No standalone binary. Consumed via Cargo path dependency by sibling crates (redbear-usbhidd, future HID drivers). This is the correct pattern for library-only Red Bear crates — they are staged as .a/.rlib artifacts for link-time consumption, not as bootable daemons. Status: Source is maintained under local/recipes/drivers/redbear-hid-core/source/. Recipe builds libredbear_hid_core.a. No init service, no scheme, no runtime daemon. Recovery: If a consumer needs it as a standalone top-level package in a config, add redbear-hid-core = {} to any config/redbear-*.toml. For normal use, the consumer crate's Cargo.toml already pulls it via path = "../redbear-hid-core" and the cookbook resolves it through the recipe dependency graph.

Decision: KEEP-ORPHAN (library-only) Reason: Pure protocol-types crate defining shared structs/enums for auth session management (AuthRequest, SessionToken, etc.). No standalone binary. Consumed via Cargo path dependency by redbear-authd and redbear-session-launch. This is the correct pattern for protocol-types-only crates. Status: Source is maintained under local/recipes/system/redbear-login-protocol/source/. Cargo lib target only. No binary targets, no init service. Recovery: If a config-level consumer needs this crate as a standalone package (e.g. a new auth client), wire it with redbear-login-protocol = {}. In practice, sibling crates pull it via path dep and the recipe-graph already covers it.

Orphan Status: redbear-passwd

Decision: KEEP-ORPHAN (library-only with potential utility binary) Reason: Provides /etc/passwd, /etc/shadow, and /etc/group parsing primitives used by redbear-authd and other authentication consumers. The recipe also builds a passwd utility binary (password change tool). As of 2026-07-28, it is wired into config/redbear-mini.toml as a first-class citizen per the FIRST-CLASS CITIZEN POLICY (Phase 3C.5). The library portion is consumed via Cargo path deps; the binary is a standalone utility. Status: Source at local/recipes/system/redbear-passwd/source/. cargo template builds both libredbear_passwd.rlib and a passwd binary. Wired in all redbear-* configs. Recovery: Already wired. If the utility binary needs init-service wrapping, add an init.d entry. If the library portion needs new consumers, add a path dep in the consumer's Cargo.toml.

Library-only Red Bear Crates — Correct Pattern

The following crates are library-only by design. They exist as recipes because the cookbook needs to stage their .rlib / .a artifacts into the sysroot so that downstream recipes can link against them. They are NOT init-service daemons:

Crate	Category	Consumers (via Cargo path dep)
`redbear-hid-core`	drivers	HID drivers, USB HID parsers
`redbear-login-protocol`	system	redbear-authd, redbear-session-launch
`redbear-passwd`	system (lib + util bin)	redbear-authd, other auth consumers
`redbear-tui-theme`	tui	tlc, redbear-power, cub, all TUI apps

Pattern: A library-only crate has:

A recipe.toml with template = "cargo" or template = "custom" building --lib
Stages to $STAGE/usr/lib/libredbear_<name>.a or .rlib
No binary targets (or a companion utility binary if applicable)
Consumer crates reference it via path = "../../../drivers/redbear-hid-core" in their Cargo.toml [dependencies]
The cookbook resolves the build order through the recipe dependencies = [...] graph

When adding a new library-only crate, follow this pattern. Do NOT create a BINS entry, an init service, or a scheme registration in a library-only crate.

Recovery and Future Wiring

Any KEEP-ORPHAN recipe can be promoted to a first-class config citizen at any time:

# In any config/redbear-*.toml [packages]:
redbear-<name> = {}

When promoting, ensure:

The recipe has a complete [package] section (name, version, description)
Build dependencies are declared
If it produces binaries, init services are wired
If library-only, consumers declare it in their recipe.toml dependencies

Never delete orphan recipes. They are kept permanently. If a recipe is entirely superseded, document the supersession here with date and replacement, but do not delete.

5.1 KiB Raw Blame History