Why I hate packaging my software for Linux
A developer vents about the nightmare of distributing a terminal app across Linux distros. Despite creating packages for everything from AppImage to AUR, none works universally. He's now betting on a statically linked musl binary with a self-updating mechanism as the primary channel, while still supporting existing packages.
I just want to GIVE AWAY MY SOFTWARE.
- kyrofa
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 it for their distros. Obviously there's a bit of a chicken and egg problem there, though, if you care about getting your software in front of users.
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.
- branc116
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/
- jorams
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. If you want to you can also build a binary with an old version of libc and distribute that to help users who don't want to compile it themselves.
Packaging it for a distro is someone else's job, and they'll take care of concerns like Debian's dependency policy. If they want to package it in the first place of course.
- _sinelaw_
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?
- xorcist
There's no end how complicated you can make things for yourself, if you really want to.
What you should do is make software good enough so your users will use it, and publish the source code under a free license. The first Debian developer that uses and likes your software will package it, and the virtous cycle can start. It can be tempting to "own" the user experience (after all, everone wants to own their customer) but one has to let go of that thought. Updates can not be expected to get pushed out the same day when you don't own the customer, but that's overall a good thing.
Ask the distro people what you can do to make their work easier, listen to them, but do not try to do their work for them. Unless you live in that distro you are unlikely to understand how they expect your software to behave and the nuances of how it should be packaged.
One of the good ideas about Linux packaging is that it is not the same people that make the software that package it. Code can be reviewed. Bad ideas can be caught. This principle is sometimes violated, but that violations happen doesn't make them a good idea. We live in a world where no one should execute random software from the Internet without any form of reputation or review, and distribution packaging suggests one way we can accomplish that. A way that has survived three decades, after all, so maybe it's worth listening to.
- rock_artist
I agree with the author.
I've made nice cross-platform pro metronome (as some use timer which is bad)
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.
- s20n
I just did a double take at "Windows and macOS aren't as bad as Linux".
Packaging for Windows is truly horrible. Even getting the dependencies to build your app on Windows is a nightmare (the author mentions winget which is no good for libraries)?
I maintain an app that uses libsfml, libfluidsynth and a bunch of other dependencies. Packaging on windows was only made possible by MSYS2 and pacman which is literally a linux package manager.
- snarfy
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.