Oof, yeah that's painful. I'm impressed you've gone to these lengths, most maintainers don't do that; they generally rely on the folks who want to use the software packaging for their distros. Bit of a chicken and egg problem there, though, obviously.
For the Debian situation specifically:
> It would've been nice if there was a quick serverless solution where you could just say a URL to look for newer versions of a single package, and both apt and dnf would remember that and update a package.
Have you considered just hosting your own Debian repo? It's basically what you're looking for here. You don't need more infrastructure, either, you can host them straight in github pages with aptly or reprepro or something, and drop new releases in there from CI.
The reason this seems so weirdly hard is that you're not supposed to be doing it. You provide sources and instructions on how to build them, and then your job is done. Users can follow those instructions. Packaging it for a distro is someone else's job, and they'll take care of concerns like Debian's dependency policy.
Apple, Microsoft, Google - none is easy meaning you need to have Play store, certs, codesign, submit... But there are steps with few results making it easy for those platform to get the software.
I have tried my best getting also Linux but as the author said, there's nothing trivial (as my metronome GitHub issues can show https://github.com/talaviram/TICK/issues)
The name is exactly the tricky part... Linux has so many flavors.
Even without installer, you have X server and Wayland and snap, AppImage, .deb each differ. add to that audio plug-in formats (CLAP, LV2, VST3) and the fact that some formats has no specific path for putting files.
For simple apps (not cli tools or ones aimed for package managers I start to think best is just providing an archive file (zip/tarball/etc)
While Linux is growing and is my goto for non-macOS, with so many releases, it still feels most users are more technical than other platforms. Add the LLM age where you can ask it to install it for you. a zip with binaries might be simplest for simple software.
The traditional way on Linux, at least in FOSS, has been to basically ship the binary somehow, also make the source available, then if people want it for Debian or whatever, they'll package it themselves. Typically, the person(s) developing the software itself are different people(s) who package it. So you'll have the application/library developer(s), then if people want it for their distribution, one of them has to decide to package it and make it available.
Of course, people nowadays try to make it easier for the distributions and provide packaging for them. But I don't think this is requirement, you can just ship a binary and most Linux users will be able to run them, and it'll basically "package itself over time" if it's interesting enough for people to want that sort of integration.
There is no right/wrong or correct/incorrect approaches here, just giving ideas :)
Hi, I'm the author of this post (and of Fresh). I've spent a lot of time getting it distributed cleanly to Linux users of all distros, and it's an uphill battle. I'm curious how other solo maintainers are dealing with this problem. Is a self updating static binary a reasonable solution?
At work we maintain embedded-linux computers with a custom distro but the actual graphical interface is a separate artifact developed by another team. Moreover they have to use an SDK that only works on a specific distro (semi-closed source).
Our solution is shipping it with its own glibc and running the executable with the LD inside this separate glibc. Basically the entire userspace. It is almost like a container but the containerization is provided by systemd and there is scoped access to limited system services via mount and network namespaces.
We cannot use static programs. Our systems have limited memory so the GUI load relevant parts of the program as shared library plugins.
This is the only reliable way to distribute closed source / independently packaged Linux software. You ship it with an entire userspace. Docker and Flatpak are just that; an admittance that distributing independent software reliably on Linux is practically impossible.
I feel like Zed, rustup, and a lot of other applications (with CLIs) moved in that direction. (Hope someone corrects me if that’s wrong, unsure those projects are fully static, but they do self update.)
As a user that surprised me at first, but I’ve grown to really like it!
TLDR is basically that you don't have to package it for others, the expectation is that people using the distributions will package it for themselves and others if the software ends up useful enough and they want it in the distribution. Until then, just ship a zipped up binary or whatever and call it a day.
Costs money and is centralized with a for-profit entity, probably best to stay far away when it comes to day-to-day software.
Don't get me wrong, I love Steam, but for video games. You can't stop auto-updating for example, and still be able to launch the "game" (program in this case) if it's out of date, which obviously breaks pretty much every professional computer user's workflow.
I think that you just need to provide .tar of your app. Everything else should be problem for people who handle packages of different distros. You don't wanna be involved in that part of distribution. If people want your app, someone will make a package. There are too many package manages for you to run and add your stuff to all of them. Just have .tar on static http server and that's it!
Example: http://ftp.klid.dk/ftp/gnu/gcc/
I use and only package for Arch. I'm a bad maintainer. If some Debian person wants it they can package it for their distro, but I don't see why it's on me to do it.
Real missed opportunity before this all got out of control to simply bundle everything needed in a single file and give it an extension that tells the OS its executable.
As someone who packaged a lot of software for Linux, I have to admit that it's bespoke and forces you to make options that come with pros and cons. But at least it _works_.
Windows? We have 1 in 100 users whose antivirus nukes a random config file. Or part of the installer. MacOS? I hope you bought a Macbook, and don't mind updating your app indefinitely.
Running Fedora Silverblue 44 as one of my desktop machines. Self updatable static binary sounds like a reasonable solution to me. But I can see why this has been a problem :/
That would work only for some people and even them will forget to check for updates. They would need a crontab or systemd timer, with git pull and the configure, compile, install pipeline. It gets unwieldy soon especially when you have to update or install dependencies.
It would work for most Linux distros, since this leans that it's (probably) open source and therefore the package maintainers could package it with the distro.
If your package is FOSS, having the distros ship it is arguably the easiest approach.
Seconded on having a distro pick it up if the package becomes sufficiently popular. Until then, the ./configure dance is delightfully universal and it makes the downstream packaging folks' jobs simpler.
If you're on a Debian-type distro the checkinstall is definitely what you want instead of `make install`. It wraps make and gives you a package that dpkg knows about.
In 20 years using Linux, I don't think this has ever worked cleanly for me. Inevitably this will fail with some mysterious missing dependencies, it won't be clear what .deb package provides them, it turns out the distro version is too old or too new...
> The next version will include a new built-in self-updating mechanism that users can trigger on demand. This will be the main release channel for Linux and hopefully the only one
This is what Mozilla is doing with Firefox. I downloaded the binary from their site and it autoupdates. Debian 11 and then 13, all is good.
For the Debian situation specifically:
> It would've been nice if there was a quick serverless solution where you could just say a URL to look for newer versions of a single package, and both apt and dnf would remember that and update a package.
Have you considered just hosting your own Debian repo? It's basically what you're looking for here. You don't need more infrastructure, either, you can host them straight in github pages with aptly or reprepro or something, and drop new releases in there from CI.
https://tick.talaviram.com
Apple, Microsoft, Google - none is easy meaning you need to have Play store, certs, codesign, submit... But there are steps with few results making it easy for those platform to get the software.
I have tried my best getting also Linux but as the author said, there's nothing trivial (as my metronome GitHub issues can show https://github.com/talaviram/TICK/issues)
The name is exactly the tricky part... Linux has so many flavors. Even without installer, you have X server and Wayland and snap, AppImage, .deb each differ. add to that audio plug-in formats (CLAP, LV2, VST3) and the fact that some formats has no specific path for putting files.
For simple apps (not cli tools or ones aimed for package managers I start to think best is just providing an archive file (zip/tarball/etc)
While Linux is growing and is my goto for non-macOS, with so many releases, it still feels most users are more technical than other platforms. Add the LLM age where you can ask it to install it for you. a zip with binaries might be simplest for simple software.
Of course, people nowadays try to make it easier for the distributions and provide packaging for them. But I don't think this is requirement, you can just ship a binary and most Linux users will be able to run them, and it'll basically "package itself over time" if it's interesting enough for people to want that sort of integration.
There is no right/wrong or correct/incorrect approaches here, just giving ideas :)
Our solution is shipping it with its own glibc and running the executable with the LD inside this separate glibc. Basically the entire userspace. It is almost like a container but the containerization is provided by systemd and there is scoped access to limited system services via mount and network namespaces.
We cannot use static programs. Our systems have limited memory so the GUI load relevant parts of the program as shared library plugins.
This is the only reliable way to distribute closed source / independently packaged Linux software. You ship it with an entire userspace. Docker and Flatpak are just that; an admittance that distributing independent software reliably on Linux is practically impossible.
As a user that surprised me at first, but I’ve grown to really like it!
I made a different post, but fits here as well: https://news.ycombinator.com/item?id=49271276
TLDR is basically that you don't have to package it for others, the expectation is that people using the distributions will package it for themselves and others if the software ends up useful enough and they want it in the distribution. Until then, just ship a zipped up binary or whatever and call it a day.
Don't get me wrong, I love Steam, but for video games. You can't stop auto-updating for example, and still be able to launch the "game" (program in this case) if it's out of date, which obviously breaks pretty much every professional computer user's workflow.
We could call it a .exe
Windows? We have 1 in 100 users whose antivirus nukes a random config file. Or part of the installer. MacOS? I hope you bought a Macbook, and don't mind updating your app indefinitely.
If your package is FOSS, having the distros ship it is arguably the easiest approach.
But not for most people.
- very slow
- need to install prerequisites
- not possible on many machines (to weak, not enough disk for running builds)
Many users don't want to deal with this
This is what Mozilla is doing with Firefox. I downloaded the binary from their site and it autoupdates. Debian 11 and then 13, all is good.