I hate packaging my software for Linux | Fresh

Skip to content

MenuReturn to top

I hate packaging my software for Linux ​<br>All I wanted was, to make Fresh easy to install, for everybody, everywhere - how hard can it be?!<br>Windows and macOS aren't so bad, because they're relatively uniform. For Windows, I use winget - ugly, but works (once I got past the initial headache). For macOS, I'm using homebrew for now, which isn't ideal, but it wasn't hard to set up. I'll probably move to a more native signed mac app once I take the time to package it correctly. Both solutions work ok for modern Windows and macOS users.<br>Linux is a different story. I started by releasing Fresh as an npm package. This felt ugly and annoyed some people on hn but also has real problems:<br>Security - npmjs has had multiple breaches and I want to sleep better at night.<br>Not universal - many users don't have npm installed, why would they install npm just to install Fresh?<br>Weird installer - the npm install flow, it's actually a script that you get from npmjs which goes to github and downloads the correct binary artifact for your machine. You have to do this every time you want to update.<br>So I listened to the annoyed people's feedback, and (with the help of several gracious contributors) we went ahead and created packages for "EVERYTHING":<br>rust's cargo on crates.io (and also cargo-binstall)<br>un-distros like AppImage and Flatpak<br>deb<br>rpm<br>AUR (Arch Linux), two variants - source build and pre-built binary -bin package<br>nix<br>mise<br>homebrew for linux (wtf?)<br>npm / npx<br>Terra<br>Gentoo GURU<br>Plus I'm releasing pre-built binaries as a tarball. You can imagine how fragile all of this can be. After each release I wonder if I'll hit some problem or another with one of the many channels.<br>Every one of those solutions works for some users but none of them work for all users. And they all have drawbacks.<br>"Why not use nix?!" ​<br>Because many people DON'T HAVE NIX installed and don't want to install it just to use my app. I support nix as a method but it doesn't work for everybody.<br>"Just use Flatpak!" ​<br>I do release a Flatpak but I'm actually working against it. It's designed for self-contained sandboxed desktop GUI applications and I'm releasing a terminal-based TUI that allows you to rampage around your machine and network. I'm passing some horrible "bad practice" flags to get it to work. Flatpak sandboxing is not a good fit.<br>"Just use AppImage!" ​<br>I do release an AppImage, but it's extremely slow to run because of the squashfs FUSE-mount on-demand, which makes bringup time unacceptably slow. I want my program to start instantly, as quickly as technically possible. To make bringup times reasonable, my installer script bakes in a horrible hack to extract the squashfs contents somewhere and drop the AppImage. You can still just run the AppImage if you prefer, but it'll be annoyingly slow to start. And in both cases it requires FUSE to be installed. Why does my app need FUSE?!<br>Also, since my binary requires some minimal libc version, it isn't actually universally portable (so for a 2-3 year old distro it might not work), hence I might as well use static linking and also just drop AppImage. For some reason I imagined that using AppImage alone solves this portability problem.<br>Lastly, for various reasons, many people have a bad view of AppImage and Flatpak (and Snap) and they would just refuse to use it. I lose.<br>Debian family pain ​<br>As explained in this other hn discussion I hadn't gotten around to pushing my .deb as a Debian (and Ubuntu) official package, because it requires all the (many) rust dependencies to also be Debian packages. There are many good reasons for this policy - fully reproducible and self-contained builds for any package, reduces supply chain hell, etc. - but it's a lot of work to do. And how will I ever keep up - every one of my direct dependencies will need to be re-updated on Debian on every security issue etc. I don't have time for that. I can't just vendor all my deps as sources into my deb source package, that goes against the policy.<br>Another fun anecdote is that I do want to support older machines running e.g. older Ubuntu (and I guess any older distro) - but these have older libc, meaning my build for newer ubuntu can't be installed on the older ones as they fail on link error at binary load time. So I'd have to build in an old Ubuntu container image and inherit its unpatched packages into my build - or drop those users entirely. Neither option holds up.<br>No automatic updates for .deb / .rpm ​<br>Because it's such a headache, I didn't get my package .deb (or .rpm) accepted into the official sources. Therefore, people who install these packages don't get automatic updates when they run their system's native package update mechanism, apt-get upgrade or equivalent. 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...