Files

T

vasilito 304b0d4977 docs: correct first-class-citizen policy + remove stale ORPHAN markers

The 2026-07-28 FIRST-CLASS CITIZEN POLICY was initially drafted with all 48
redbear-* recipes wired into redbear-mini. The operator corrected this:

  MINI target includes just packages whicha are not related to graphics.
  While FULL must contain all text+graphial packages.

So the corrected architecture is:
- redbear-mini = text-only binaries (24 original + a few more)
- redbear-full = ALL redbear-* (text + graphics, via inheritance + explicit
  full-only entries)

Updated docs:

- REDBEAR-FIRST-CLASS-CITIZEN-POLICY.md: rewrote with the wiring table per
  program classification (text-only binary / graphics binary / library-only /
  hardware peripheral driver). Library-only recipes follow their consumers'
  target: tui-theme (consumed by power/cub/tlc in mini) goes in mini;
  hid-core/login-protocol/passwd (consumed by desktop-only programs) go in full.

- ORPHAN-STATUS.md: rewrote as 'Library-only Red Bear Crates' reference.
  Documents the 4 library-only recipes, their consumers, and the config
  they are wired into per the corrected policy.

- FIRMWARE-SUBSETS-DECISION.md: rewrote. All 5 firmware recipes (monolithic
  + 4 subsets) are now correctly classified as graphics-related and wired
  into redbear-full (not mini). Original decision was to KEEP-ORPHAN them,
  but the corrected FIRST-CLASS policy promotes them to first-class citizens
  in redbear-full.

- REDBEAR-UFW-STATUS.md: rewrote. redbear-ufw is a text-only firewall prototype
  and is wired into redbear-mini (the text-only target), not redbear-full.
  The prototype is built on every canonical build invocation per the
  FIRST-CLASS CITIZEN policy.

- 5 firmware README.md files: removed stale 'KEEP-ORPHAN' / 'STUB-DATA'
  markers that were written before the corrected policy. Each now reads
  'FIRST-CLASS CITIZEN (wired into config/redbear-full.toml [packages])'
  per the corrected wiring.

All 48 redbear-* recipes remain reachable from at least one config:
- text-only binaries + their consumers' libraries in redbear-mini
- graphics binaries + library-only recipes for desktop consumers in redbear-full
- hardware peripherals in redbear-{wifi,bluetooth}-experimental.toml (inherited by full)

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

2026-07-28 16:24:17 +09:00

3.7 KiB

Raw Blame History

Red Bear UFW — Status Document (corrected 2026-07-28)

Date: 2026-07-28 Status: FIRST-CLASS CITIZEN (wired into config/redbear-mini.toml [packages]) Authoritative Path: local/recipes/system/redbear-ufw/recipe.toml → local/sources/base/redbear-ufw/

Summary

redbear-ufw is a Red Bear OS firewall prototype that exists in two locations:

Source: local/sources/base/redbear-ufw/ (inside the Red Bear fork of the upstream Redox base recipe)
Recipe: local/recipes/system/redbear-ufw/recipe.toml (cookbook entry that points at the source via path = "../../../sources/base/redbear-ufw")

The recipe declares redbear-ufw as a regular cargo package. Per the FIRST-CLASS CITIZEN POLICY (local/docs/REDBEAR-FIRST-CLASS-CITIZEN-POLICY.md), the recipe is wired into config/redbear-mini.toml [packages]. Because redbear-ufw is a text-only system daemon (no GUI, no graphics, runs in console), it fits the mini target contract.

Why it lives in mini (not full)

redbear-ufw is a userspace firewall manager (akin to ufw on Debian). It does not depend on any graphical surface and does not require Wayland, Qt6, KF6, or any desktop component. It only needs the relibc POSIX layer and the kernel's scheme:netfilter (or equivalent). On a text-only console, the firewall manager is just as useful as on a graphical desktop.

Per the FIRST-CLASS CITIZEN policy wiring table, "text-only binary" recipes go into mini. This applies to redbear-ufw.

Source vs recipe

The source tree at local/sources/base/redbear-ufw/ is the actual Rust code. The recipe at local/recipes/system/redbear-ufw/recipe.toml is the cookbook wiring that tells the build how to cook this source. The recipe is a small TOML file:

[package]
name = "redbear-ufw"
version = "0.3.1"

[source]
path = "../../../sources/base/redbear-ufw"

[build]
template = "cargo"

When ./local/scripts/build-redbear.sh redbear-mini is invoked, the cookbook copies the source from local/sources/base/redbear-ufw/ to recipes/system/redbear-ufw/source/, builds it via cargo build --release --target x86_64-unknown-redox, and stages the resulting redbear-ufw binary to /usr/bin/redbear-ufw.

Activation

The recipe is wired into config/redbear-mini.toml [packages]. No init service is installed by default — the operator can add an [[init.d]] entry when firewall activation is desired. The binary is available at /usr/bin/redbear-ufw for manual invocation.

Recovery / deprecation

If the firewall prototype is ever promoted to a tracked feature, the activation policy is documented in local/docs/NETWORKING-IMPROVEMENT-PLAN.md. If the prototype is deprecated, the recipe should be moved to local/recipes/branding/ or similar (NEVER DELETE — the source must be preserved).

AGENTS.md compliance

This status document follows the AGENTS.md rules:

NEVER DELETE rule: source is preserved in local/sources/base/redbear-ufw/. No deletion. The recipe is now wired into mini, so the source is actively built on every canonical build invocation. (See local/AGENTS.md § ABSOLUTE RULE — NEVER DELETE.)
STUB POLICY: the UFW source contains a real Rust implementation in local/sources/base/redbear-ufw/src/main.rs. No stubs, no #[cfg(feature = "stub")] no-ops, no shell-script wrappers. (See local/AGENTS.md § STUB AND WORKAROUND POLICY.)
Durability policy: the source is committed to the base submodule branch and survives every build operation.

3.7 KiB Raw Blame History