How the Generic-Linux SIG approached cross-distribution support in 2025

Original publication: 2025-09-29. English edition and practical reading notes: Linglong editorial, 18 October 2026. Chinese original.

The 29 September 2025 community article described the Linyaps Generic-Linux SIG’s work on distributions beyond deepin. Its opening compared the friction of packaging the same application for different systems and presented lighter packaging and startup as the project’s motivations. Those comparisons were the article’s claims, not controlled measurements in this edition.

From an Ubuntu experiment to a SIG

The article traced the group to mozixun, who wanted the responsiveness he had experienced with Linyaps on deepin on other systems. In August 2024 he was already compiling and running it on Ubuntu, but occasional problems showed the difference between working in principle and a reliable everyday experience. He contacted the Linyaps team, reported issues and worked through adaptation details.

In October 2024, Ziggy asked in the community whether anyone was using Linyaps outside deepin. After hearing about mozixun’s Ubuntu work, he proposed a SIG. Its initiator was still learning packaging tools such as debuild, but accepted the task. Contributors with different distribution and desktop-testing experience joined to improve adaptations and collect feedback.

The contributions highlighted

• System-tray behavior: the article described DingTalk, QQ Music and WeChat competing for tray visibility. mozixun traced the issue to Electron compatibility and submitted an issue that helped the team address it. Its comparison with Flatpak is the source’s account, not an independently reproduced test.
• Office applications: work on WPS included a KDE Plasma problem with creating office documents from the context menu, alongside maintenance of commonly used office software.
• Shared runtimes: GTK4 and WebKit2GTK runtime work aimed to avoid carrying the same libraries in Tauri packages. The article reported an application package falling from over 200 MB to the teens of MB. That is a reported package example, not a full installed-size or startup benchmark. Flutter work was another part of the contribution.

The RPM-family route in the article

The SIG used a third-party Fedora Copr project. The article listed AMD64/ARM64 adaptations for Fedora 42, 43 and Rawhide; EPEL 9/10 systems such as RHEL, Rocky Linux and AlmaLinux; and openEuler 24.03 LTS. It noted that openEuler required a UTF-8 default locale.

The historical Fedora/RHEL instructions enabled Copr; RHEL-family systems first needed the matching EPEL release repository. openEuler used a separately downloaded repository file.

sudo dnf copr enable mozixun/OpenAtom-Linyaps
sudo dnf update && sudo dnf install linglong linglong-bin linglong-builder linglong-pica linyaps-web-store-installer -y

These commands are a record of the 2025 article and change the machine. They are not a current universal installation instruction. The source linked to its openEuler repository file.

Debian, Arch and NixOS

• Debian family: maintained by 核动力四号机组 and mozixun, with releases at the Gitee project. The article listed Ubuntu 22.04/24.04 LTS, then-current 25.04, and Debian Stable/Sid. It advised matching an Ubuntu derivative to its upstream release, giving Linux Mint 22 → Ubuntu 24.04 as an example and mentioning Pop!_OS and TUXEDO OS.
• Arch Linux: credited 饕餮人 and linked to taotieren/aur-repo, described as 0BSD-licensed.
• NixOS: credited wineee and linked to nix-community/linyaps-flake.

Testing and participation

The article said SIG members had tested the listed adaptations, while also asking for more reports across hardware, distributions and usage scenarios. It gave SIG QQ group 892130154 as a historical contact route and invited participation in the wider community. Those reports and contacts are not a permanent compatibility guarantee or confirmation of a currently open group.

Turn a compatibility claim into a useful record

1. Match the distribution release, CPU and desktop, not just “Linux”.
2. Identify the package source and its maintainer; a third-party repository is a trust decision.
3. Read the matching current installation reference before changing repository configuration.
4. In a recoverable test environment, check install, launch, file access, tray/desktop integration and an application-specific task.

Distribution / release / CPU / desktop:
Source URL / maintainer / package version:
Linyaps / base / runtime versions:
Install and launch:
File access and desktop integration:
Application task and observed failure:
Evidence date:

Read the versioned installation reference. The diagram classifies the routes in the 2025 article, not a matrix of newly passed tests.