diff --git a/CONCLUSIONS.md b/CONCLUSIONS.md new file mode 100644 index 0000000..2e53514 --- /dev/null +++ b/CONCLUSIONS.md @@ -0,0 +1,169 @@ +# Conclusions: Yino Project Post-Mortem + +> Written: 2026-02-21 +> Status: Project abandoned +> Duration: ~1 week (2026-02-15 to 2026-02-21) + +## What Yino was + +Yino ("Yino Is Not Omarchy") was an attempt to port [Omarchy](https://github.com/basecamp/omarchy) — an +opinionated, keyboard-driven Hyprland desktop environment built on Arch Linux — to a stable Debian base. + +The motivation was simple: Omarchy's curated desktop experience is excellent, but Arch Linux's rolling +release model introduces instability. Debian's conservative, long-term-support release cycle seemed like +the ideal stable foundation to deliver the same experience without the rolling-release risk. + +## What we built + +- A QEMU VM helper (`bin/yino-vm`) with KVM acceleration for development and testing +- A preseed configuration (`iso/preseed.cfg`) achieving unattended Debian installation with LUKS + btrfs +- ISO build tooling for injecting preseed and packages into the stock Debian DVD image +- Comprehensive requirements documentation (`REQUIREMENTS.md`) with 87 numbered requirement IDs +- A detailed upstream analysis (`docs/Omarchy.md`) mapping Omarchy's full architecture at commit `463417a` +- An Arch-to-Debian package mapping covering ~100+ packages across all components + +## The core problem: Hyprland doesn't fit stable distros + +The central discovery of this project is that **Hyprland is too fast-moving for any traditional stable +Linux distribution to keep up with.** + +### Debian + +The entire Hyprland ecosystem was deliberately removed from Debian Trixie (stable) via +[Debian Bug #1107152](https://bugs.debian.org/1107152). Hyprland remains in sid (unstable), but +installing sid packages on a stable base is a known source of dependency conflicts and system +instability — the exact problem Yino was trying to avoid. + +The Yino approach was to download Hyprland ecosystem packages from sid, cache them, and slipstream them +into the installation ISO. This is workable in theory but creates a significant maintenance burden: + +- **12+ packages** from the Hyprland ecosystem need to be sourced from sid +- **Library compatibility** between sid packages and the Trixie base is not guaranteed +- **Every Debian stable point release** could break the cached sid packages +- **Every Hyprland update** requires re-testing against the Trixie base +- **Several additional packages** (Walker, Ghostty, Hyprsunset) aren't in Debian at all and need to be + built from source + +### Fedora (investigated as alternative) + +Initially, Fedora appeared promising — semi-stable with 6-month releases and what we believed was a +Hyprland Spin. **Investigation revealed this was wrong on both counts:** + +- **There is no Fedora Hyprland Spin.** It doesn't exist, has never existed, and has no proposal in the + pipeline. The Fedora Sway Spin exists; Hyprland does not. +- **Hyprland was retired from Fedora 43.** The package was present in Fedora 41 and 42, but was removed + from Fedora 43 because `hyprland-qtutils` depended on Qt 6.9 private APIs, and Fedora 43 moved to + Qt 6.10. Nobody stepped up to fix it. It was flagged via Bugzilla #2366813 as "F43FailsToInstall" and + subsequently retired (Pagure issue #12969). +- **Community COPR repos** (`solopasha/hyprland`, `sdegler/hyprland`, etc.) exist but are volunteer- + maintained and fragile. + +Fedora's Hyprland situation is arguably **worse** than Debian's — Debian at least still has Hyprland +in sid. Fedora's packaging is entirely gone from official repos and trending in the wrong direction. + +### openSUSE Tumbleweed (investigated as alternative) + +Tumbleweed is the strongest traditional option for Hyprland: + +- Hyprland is in **official repos** and actively maintained +- Btrfs + Snapper is Tumbleweed's flagship feature (they pioneered the pattern Omarchy adopted) +- KIWI image builder is world-class ISO tooling +- openQA automated testing catches regressions before they reach users + +However, Tumbleweed is a **rolling release** — continuous updates, not periodic stable releases. This +conflicts directly with the project's goal of providing a stable, predictable base. The whole point of +Yino was to escape rolling-release churn, and Tumbleweed — however well-tested — is still rolling. + +### NixOS (investigated as alternative) + +NixOS is the most philosophically interesting option: + +- Hyprland is well-maintained in nixpkgs with first-class NixOS module support +- The entire system is defined declaratively in configuration files — which aligns perfectly with + "an opinionated set of configuration files" +- Versions are pinned, updates happen when you choose, rollbacks are atomic +- ISO generation is trivial (a Nix expression) +- `henrysipp/omarchy-nix` (657 stars) demonstrates significant community interest + +However, NixOS represents a **complete paradigm shift** from Omarchy's architecture. Omarchy is shell +scripts overlaying dotfiles onto a traditional Linux system. NixOS would require reimagining the entire +project as a Nix flake with home-manager modules. This violates the "match upstream Omarchy" design +principle that was paramount for Yino. + +## The landscape at a glance + +| Distribution | Hyprland in official repos | Stability model | Trend | +|:---|:---:|:---|:---| +| Arch Linux | ✅ Always | Rolling (untested) | Stable — it's the native platform | +| Debian sid | ✅ Yes | Unstable | Was in testing, yanked from stable | +| Debian Trixie | ❌ Removed | Stable | Gone (Bug #1107152) | +| Fedora 43 | ❌ Retired | 6-month releases | Gone (Qt 6.10 breakage) | +| Fedora COPR | ⚠️ Community | Fragile | Depends on volunteers | +| openSUSE TW | ✅ Official | Rolling (QA-tested) | Healthy | +| NixOS | ✅ Official | Pinned by user | Very healthy | + +**Only rolling distros and NixOS maintain healthy Hyprland packaging.** Every traditional stable distro +has dropped it. + +## Related community projects + +During research, we found these existing efforts to port Omarchy to other bases: + +| Project | Base | Stars | Notes | +|:---|:---|---:|:---| +| `henrysipp/omarchy-nix` | NixOS | 657 | Full Omarchy port as a Nix flake | +| `elpritchos/omadora` | Fedora | 70 | Minimal Fedora + Hyprland, Omarchy-like | + +The NixOS port has nearly 10x the community interest of the Fedora attempt, suggesting the declarative +approach resonates more strongly with the audience that wants "Omarchy but not on Arch." + +## Why we're stopping + +The fundamental tension is irreconcilable: + +> **Hyprland moves fast. Stable distros move slow. Bridging this gap is a full-time packaging job, +> not a configuration project.** + +Yino was conceived as "an opinionated set of configuration files" — the same identity as Omarchy. +But on Debian (or Fedora), the project would spend most of its effort on **packaging** (building, +caching, testing, and maintaining 12+ Hyprland ecosystem packages against a stable base), leaving +little room for the actual value proposition: the curated desktop experience. + +On Arch, Omarchy can focus on the experience because the packaging is handled by the distribution. +On any stable distro, Yino would have to handle both — and the packaging burden dominates. + +## What would change this conclusion + +- **Hyprland stabilizes its ABI** and gets re-accepted into Debian stable or Fedora — unlikely given + the ecosystem's development velocity +- **A third party maintains Hyprland packages for Debian/Fedora** reliably (a PPA, COPR, or OBS repo + with serious commitment) — possible but not something to bet a project on +- **The project embraces NixOS** and accepts the paradigm shift — viable, and `omarchy-nix` proves + demand exists, but it's a different project with a different identity +- **The project embraces Tumbleweed** and accepts rolling release (with snapshot safety) — the most + natural fit technically, but contradicts the original motivation + +## Open questions that were never resolved + +These were identified during requirements analysis but never investigated due to the project being +abandoned: + +- **OQ-001:** Would the Hyprland stack from sid actually install cleanly on Trixie, or would it pull + cascading dependencies that destabilize the system? +- **OQ-002:** What are Walker's build dependencies? Static binary or proper .deb packaging? +- **OQ-003:** Ghostty sourcing — build from source (Zig toolchain), community .debs, or use Alacritty? +- **OQ-004:** Hyprsunset vs. wlsunset — is the Omarchy-compatible version worth the build effort? +- **OQ-006:** ISO build tool choice — live-build, simple-cdd, or manual remastering? + +## Artifacts produced + +All artifacts remain in the repository for reference: + +| File | Description | +|:---|:---| +| `REQUIREMENTS.md` | Full requirements document (87 requirement IDs, user stories, acceptance criteria) | +| `docs/Omarchy.md` | Comprehensive Omarchy analysis at commit `463417a` (architecture, packages, ISO, theming) | +| `docs/yino-fsd.md` | Functional specification document | +| `iso/preseed.cfg` | Working preseed config for unattended Debian install (LUKS + btrfs + Hyprland) | +| `bin/yino-vm` | QEMU VM helper with KVM acceleration | +| `CONCLUSIONS.md` | This document |