DevOps for Desktop Environments

Posted Sep 11, 2025 13:49 UTC (Thu) by raven667 (subscriber, #5198)
Parent article: KDE launches its own distribution (again)

> The process of creating and refining KDE Linux will satisfy that for KDE developers, but it may also serve another purpose: to demonstrate just how difficult it is to create and maintain a desktop distribution for widespread use. Whether KDE Linux succeeds as a standalone distribution or not, it may be a useful exercise to illustrate why projects like Debian, Fedora, openSUSE, Ubuntu, and others make choices that ultimately frustrate application developers.

Wow.

This is ultimately the original idea for "DevOps" which is that you need feedback from direct experience to better understand the pain points and severity of issues when actually _using_ and _maintaining_ software as part of a larger system, where "it works on my machine" might not be the most effective strategy for prioritizing issues.

This might also be a good test to see how useful the `systemd-sysupdate` infrastructure is, as I'm not sure how much uptake there has been for it (maybe embedded devices that fly under our collective awareness) as most desktop-user-facing distros have their own methods which predate systemd.

I'd need to read the linked mail threads but I wonder about the decision to move away from Arch, isn't SteamOS shipping KDE on an Arch-derived base, making that one of the most common configurations of KDE that people who aren't software developers or IT professionals would encounter? ISTM that aligning testing and dogfooding around the ecosystem of what I presume is their largest and growing userbase would make for the best experience for the most people. If they make their development process have less friction when using their own self-hosted distro, but more friction when distributed on Debian, Fedora, SteamOS/Arch, Ubuntu, SuSE, etc. then I'm not sure that's winning. As you say though if a wider base of KDE developers have the experience of shaping a distro then they may shave off some of the friction which improves the experience across all distros. I don't know which is more likely, we'll see.

DevOps for Desktop Environments

Posted Sep 11, 2025 13:58 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> Reasons to switch from Arch: https://invent.kde.org/kde-linux/kde-linux/-/issues/225

> Simplicity: Violates the "no packaging knowledge required to develop it" aspiration, because now you do need to understand something about Arch PKGBUILD files and how they're produced and consumed.

I don't see how you develop a distro without needing to learn some way to manage the underlying base OS dependency tree, so I don't think you can develop a whole distribution mechanism without learning something specific to that workflow.

> Breaks distro-agnosticism: In principle KDE Linux aspires to be agnostic about the base distro, so that swapping it out for another one is easy. With the packages pipeline producing a local AUR repo and PKGBUILD files, that isn't true anymore.

I don't think this is achievable either, there are going to be systems which are better tested and aligned with the needs of KDE and systems which are less tested and aligned, creating their own distro just adds another flavor to support, it doesn't make it more agnostic. They should pick a mechanism for maintaining their base OS that works well for them and not be so concerned about the "purity" of it and of not picking favorites. At least that's my opinion, I'm not a KDE developer (or user anymore) so I don't have a stake in the outcome, just random opinions that I'm willing to share ;-)

DevOps for Desktop Environments

Posted Sep 11, 2025 14:02 UTC (Thu) by jzb (editor, #7867) [Link] (1 responses)

I'd need to read the linked mail threads but I wonder about the decision to move away from Arch

It's possible I didn't make this part clear enough or put in enough detail: the KDE Linux team wants to move away from using the AUR packages, not Arch itself. Being distribution-agnostic is a goal, but AFAIK they are not trying to move away from Arch right now, just end the dependency on AUR for security reasons and also because the AUR has had outages lasting multiple days. Apologies that I didn't make that more clear.

DevOps for Desktop Environments

Posted Sep 11, 2025 18:54 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I'm just not as familiar with the Arch ecosystem tooling as I am with RPM/dnf or dpkg/apt so I just wasn't picking up what you were laying down, it sounds like the Arch User Repository is something like Fedora copr or Ubuntu PPA, a semi-official place to host custom repos aligned with the larger distro project but not part of it that maybe shares some of the CI tooling (like koji or obs). Am I understanding that more or less correctly?

Self-hosting makes sense but if they have things which they need as part of the base OS build which aren't part of their own project and the apps they are layering on, it still makes sense to me to manage that using the tools one uses to build a distro, even if the output is just a filesystem image. ISTM you end up needing the kinds of tools distros use, to track dependencies or script build processes, and the distros each have a well-tested maintained ecosystem for doing that kind of work, maintaining a cohesive suite built out of disparate projects.

eg for my own department I have three levels of packaging, all using RPM/dnf, my in-house developed software where we make RPMs for everything built using Gitlab CI with `tito` in a main repo, 3rdparty code where we are just the packager which also gets built with Gitlab CI using `rpmbuild` in a similar fashion to `tito`, and the base OS packages which are any yum repo I can configure which is maintained outside of our org (like RHEL, EPEL or PostgreSQL). When everything fits into the OS tooling then you can build systems just using `dnf install`, you don't need a separate process to manage additional libraries or a custom deployment/upgrade process for in-house software, it just uses the OS tools for that.

As I said I don't know the Arch tooling and how its different or what the conventions are for vendors using it to build systems, but ISTM that one could easily end up building a worse set of bespoke scripts and process to do what PKGBUILD/pacman already do, just to avoid *seeming* to be biased, rather than taking advantage of whatever unique capability the base OS gives you.

So I'm hoping they are just self-hosting a custom Arch repo to manage all the parts needed for KDE Banana and not eschewing packaging for anything above the base OS from Arch as that seems like more work for less gain.