Michael Smith
6c6a82937f
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>
170 lines
8.9 KiB
Markdown
170 lines
8.9 KiB
Markdown
# 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 |
|