DevOps for Desktop Environments

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.