kevinveenbirkenbachandClaude Opus 4.7
16bdbf03d7
Three classes of drift cleaned up across 85 .md files:
- Em-dashes: replaced ` — ` with the contextually correct separator
(colon for `term: explanation`, period to split clauses across
sentences/source lines, parentheses for asides, semicolon for
tight-linked continuations). Two intentional exceptions remain
in `docs/contributing/documentation.md` (the rule literal) and
inside a fenced ```sh block in `docs/contributing/actions/debugging/ci.md`.
- SPOT self-labels: rewrote "This is the SPOT for X" to describe
the subject directly ("This directory holds X" / "This file
describes X"). Cross-references to other artefacts' canonical
role remain unchanged.
- Heading-emoji position: moved leading-emoji headings (`# 🧩 Title`)
to trailing position (`# Title 🧩`) per the headline rule that
emojis MUST come after the title text.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5.2 KiB
Supported Operation Systems
This page defines which operating systems deployments, scripts, and programs MUST support. Following this policy ensures that Infinito Nexus runs reliably across a broad range of server environments, from community-managed long-term-support servers to enterprise Red Hat deployments and cutting-edge rolling-release development machines.
Deployed Systems
All deployment roles, Ansible tasks, and programs that run inside a deployed system MUST be compatible with the following distributions.
Supporting this set gives operators a choice between stable community servers, enterprise-grade Red Hat-compatible systems, and a rolling-release target for early-integration testing.
| Distribution | Family | Purpose | Advantages | Disadvantages |
|---|---|---|---|---|
| Debian | Debian | Preferred for stable, long-term community production deployments | Exceptional stability, large community, predictable release cadence, broad package availability | Packages lag behind upstream; slower to adopt new software versions |
| Ubuntu | Debian | Primary CI and development target; widely used on cloud infrastructure | Large ecosystem, good tooling support, frequent LTS releases, broad cloud image availability | Canonical-managed; some divergence from pure Debian behaviour |
| Fedora | Red Hat | Required for Red Hat compatibility validation | Close to RHEL/CentOS Stream upstream; early access to new packages; strong SELinux support | Shorter support window; not suitable for production long-term deployments |
| CentOS | Red Hat | Required for Red Hat enterprise compatibility | RHEL-compatible; used in enterprise environments; long support cycles (Stream variant) | CentOS Stream is rolling; classic CentOS EOL; smaller community than Debian/Ubuntu |
| Arch Linux | Arch | Required for rolling-release development and early-integration testing | Always up-to-date packages; minimal base; fast feedback on upstream changes | No stable release; higher breakage risk; not suitable for production servers |
Why this set? Debian is preferred for stable community-operated servers because it offers long-term support without commercial backing requirements. Fedora and CentOS are required to ensure compatibility with Red Hat Enterprise Linux (RHEL) environments. Red Hat support MUST be guaranteed because enterprise customers operate under SLA and security compliance requirements that mandate a RHEL-compatible platform, including certified package versions, SELinux enforcement, and vendor-backed security advisories. Arch Linux is included to catch integration problems with newer software versions early in the development cycle before they reach stable distributions.
Requirements
- Deployment roles and programs MUST work on all five distributions listed above.
- Roles MUST NOT rely on distribution-specific package names without an explicit per-family branch or variable.
- Debian SHOULD be the primary reference distribution when behaviour differs across families.
- Arch Linux support MAY use the latest available package versions where no stable equivalent exists.
Local Test and Setup Environment
Scripts used for local testing and setup (under scripts/tests/ and scripts/install/) MUST
support all five deployed distributions above and additionally MUST support:
| Platform | Purpose | Advantages | Disadvantages |
|---|---|---|---|
| WSL2 (Windows Subsystem for Linux) | Required for Windows-based developer machines | Allows contributors on Windows to run the full local stack without a separate VM | Requires systemd configuration; networking differences from native Linux |
| Homebrew (macOS) | Required for macOS-based developer machines | Standard package manager on macOS; widely used in CI runners | Package names and paths differ from Linux distributions; some tools behave differently |
Requirements
- Local setup and test scripts MUST work on all five deployed distributions.
- Local setup and test scripts MUST additionally support WSL2 and Homebrew (macOS).
- Scripts SHOULD use
command -vor equivalent to detect available tools rather than assuming a specific package manager. - Scripts SHOULD skip steps silently when a tool is not available only if a working alternative exists or the step is purely informational. Scripts MUST fail hard when a required tool is missing and no alternative is available.
- Scripts MUST NOT hard-code paths that only exist on one distribution family (e.g.
/usr/lib/python3without a fallback). - WSL2-specific steps MUST be guarded by a WSL2 detection check before execution.
- macOS-specific steps MUST be guarded by an
unameorcommand -v brewcheck before execution.