m/yino
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add project post-mortem documenting why Yino is being abandoned

Browse Source 
The core finding: Hyprland is too fast-moving for any traditional stable
distro. Debian removed it from Trixie, Fedora retired it from F43, and
bridging the gap requires a full-time packaging effort that overshadows
the actual value proposition of a curated desktop experience.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Michael Smith 2026-02-21 17:46:00 +01:00
parent 0453470cde
commit 6c6a82937f
1 changed files with 169 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

169
CONCLUSIONS.md Normal file
View File

@ -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 |