Multi-OS support roadmap: extend beyond Ubuntu (Debian/RHEL/Arch/Gentoo/Alpine/NixOS/BSD families)

[darkn3rd]

Right now scriptbox/config/ only has one Linux/Unix target, ubuntu2204.yml. The eventual goal is real support across a much wider set - Rocky Linux, Fedora, AlmaLinux, Debian, Linux Mint, elementary OS, Pop!_OS, Zorin, Arch Linux, CachyOS, Gentoo, Alpine Linux, NixOS, SmartOS, FreeBSD, DragonFly BSD - but working on 14+ distros at once, testing n*(n-1) combinations, isn't realistic right now. This issue exists to track the infrastructure that makes adding each one later fast (minutes, not days) rather than a copy-paste avalanche of per-distro tech debt, and to be torn apart into individual per-OS issues as each one actually gets picked up.

Why this matters now, even with one real target

Building this generically today - while there's only one consumer (Ubuntu) - is deliberate: retrofitting a "one platform hardcoded" design later, once several distro manifests already exist, is far more expensive than designing the extension points now. The goal:

• Abstractions similar to a real CM tool, so there's an easier 1:1 mapping between manifest intent and generated output, the same way Chef's own apt_repository resource is one clean abstraction instead of a hand-rolled script
• Reduce heavy reliance on custom, inconsistent imperative scripts - less generated-script complexity per platform
• DRY - common patterns (a shared shell function, a repo-add primitive) live in one place, not copy-pasted per distro

Infrastructure already landed

• env.yml's own environments: entries can carry a lineage: field (e.g. ubuntu22 → lineage: debian) - author-declared OS ancestry, not /etc/os-release probing at generation time, mirroring how ID/ID_LIKE actually chains (a single value normally; an ordered most-specific-first list like [ubuntu, debian] is also supported, for the rarer case a real per-distro tier is needed - e.g. client-server config like firewalls, not simple package installs)
• scriptbox/config/helpers/<lineage-name>.yml - shared shell functions any platform in that lineage can pull in (debian.yml's own add_apt_repo, the raw signed-by-key+list-file repo pattern, is the first one), rather than every platform's own scripts: block duplicating the same function body
• A scripts: entry declares uses: to pull in whichever shared helper(s) its own cmd: body actually calls (explicit, not text-scanned)
• add_apt_repos: + a package entry's own add_apt_repo: field - the non-PPA way to add a repo (a name into add_apt_repos:, resolved to the real fields), rendered as a call to the shared add_apt_repo() function on the bash side, and as Chef's own native apt_repository resource (key/uri/distribution/components) on the Chef side - both already implemented and verified end-to-end

What's still ahead per new OS family

• A real second Debian-lineage manifest (Debian proper, Mint, Pop!_OS, ...) to prove the lineage:/helpers/ mechanism actually works across more than one consumer, not just in the abstract
• RHEL/Fedora-lineage family: dnf/yum package type, helpers/rhel.yml, repo-add primitive equivalent to add_apt_repo (likely wrapping dnf config-manager --add-repo / a .repo file write)
• Arch-lineage family (Arch, CachyOS): pacman already exists as a PACKAGE_TYPES entry in resolve_order.rb/generate_install_script.rb, but is untested against a real Arch manifest; AUR handling undecided
• Gentoo: portage/emerge - fundamentally different model (source-based, USE flags) from every other family here, needs its own design pass, not just a new package type
• Alpine: apk - musl libc means some existing lesson scripts (rbenv/pyenv installers, sdkman, etc.) may not work unmodified even once apk itself is wired up
• NixOS: fundamentally different package/config model (declarative, immutable) - likely doesn't fit the existing imperative-script generator shape at all; needs its own investigation before committing to an approach
• SmartOS (illumos/SunOS-based) and FreeBSD/DragonFly BSD (BSD-based): neither is Linux, neither has /etc/os-release the way the lineage: mechanism assumes - detection and package management (pkgsrc/pkg) both need their own approach

Each one of these, once actually started, should become its own scoped issue rather than growing this one indefinitely.