Releases currently ship an AppImage (the jammy pair, portable to any glibc 2.35+ system), an Arch .pkg.tar.zst, a PKGBUILD, and package.nix for Nix users. There is no native .deb or .rpm.
Native packages would be better than an AppImage for the distros they target: dependencies resolved by the system package manager, 69-sc-controller.rules installed to the right place automatically, proper desktop integration, and updates that arrive with the rest of the system rather than by re-downloading a file.
Not urgent. Filed so the idea is tracked rather than lost.
What this is not
A note for whoever picks this up: the fedora:43 / fedora:44 / ubuntu:resolute entries in .github/workflows/appimage.yml are test targets — stock images pulled to run the finished AppImage, with only libX11 added. They are not build environments and there is nothing there to reuse. The AppImage build bases are Ubuntu jammy/noble/resolute and Debian bookworm/trixie.
The part that decides the approach
One .deb is not "deb support". A package built against Ubuntu resolute will not install cleanly on Debian 12 or Ubuntu 22.04, and a Fedora 44 .rpm is not a Fedora 43 package. Covering what the single jammy AppImage covers today means a matrix of native packages, each needing its own dependency-name mapping (python3-gobject vs python-gobject, and so on) maintained per release.
That is the same shape as the problem in TODO.md under "Release assets that are attached by hand", and it multiplies it.
So the options, roughly in order of leverage:
- COPR (Fedora) and OBS (openSUSE Build Service) — OBS builds both
.deb and .rpm for many targets from one source package, and both give users a repository, which is where the real benefit of native packaging lives. Highest value, and the maintenance lands in one spec rather than N CI jobs.
- Getting into the distributions' own repositories — the best outcome for users, the most work, and not something this project controls unilaterally.
fpm in CI — cheapest to try: one command against the installed tree yields a .deb or .rpm. Worth knowing what it actually buys, though: a package that works on the distro it was built on, which is close to what the AppImage already does, minus the portability.
Adding hand-rolled per-distro jobs to appimage.yml is the option to avoid — it takes on the recurring cost of native packaging without delivering the repository that makes it worthwhile.
Prerequisite
Whatever route is chosen, the release-asset automation in TODO.md should come first. Three assets are already attached by hand every release; adding two more formats before that is fixed makes the manual step worse, and v0.6.0.8 already shipped incomplete once because of it.
Releases currently ship an AppImage (the jammy pair, portable to any glibc 2.35+ system), an Arch
.pkg.tar.zst, aPKGBUILD, andpackage.nixfor Nix users. There is no native.debor.rpm.Native packages would be better than an AppImage for the distros they target: dependencies resolved by the system package manager,
69-sc-controller.rulesinstalled to the right place automatically, proper desktop integration, and updates that arrive with the rest of the system rather than by re-downloading a file.Not urgent. Filed so the idea is tracked rather than lost.
What this is not
A note for whoever picks this up: the
fedora:43/fedora:44/ubuntu:resoluteentries in.github/workflows/appimage.ymlare test targets — stock images pulled to run the finished AppImage, with onlylibX11added. They are not build environments and there is nothing there to reuse. The AppImage build bases are Ubuntu jammy/noble/resolute and Debian bookworm/trixie.The part that decides the approach
One
.debis not "deb support". A package built against Ubuntu resolute will not install cleanly on Debian 12 or Ubuntu 22.04, and a Fedora 44.rpmis not a Fedora 43 package. Covering what the single jammy AppImage covers today means a matrix of native packages, each needing its own dependency-name mapping (python3-gobjectvspython-gobject, and so on) maintained per release.That is the same shape as the problem in
TODO.mdunder "Release assets that are attached by hand", and it multiplies it.So the options, roughly in order of leverage:
.deband.rpmfor many targets from one source package, and both give users a repository, which is where the real benefit of native packaging lives. Highest value, and the maintenance lands in one spec rather than N CI jobs.fpmin CI — cheapest to try: one command against the installed tree yields a.debor.rpm. Worth knowing what it actually buys, though: a package that works on the distro it was built on, which is close to what the AppImage already does, minus the portability.Adding hand-rolled per-distro jobs to
appimage.ymlis the option to avoid — it takes on the recurring cost of native packaging without delivering the repository that makes it worthwhile.Prerequisite
Whatever route is chosen, the release-asset automation in
TODO.mdshould come first. Three assets are already attached by hand every release; adding two more formats before that is fixed makes the manual step worse, and v0.6.0.8 already shipped incomplete once because of it.