yino/CONCLUSIONS.md

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 — 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. 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