I hate packaging my software for Linux

_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?

jjgreen

./configure make sudo make install

pmontra

> 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.

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.

rock_artist

I agree with the author. I've made nice cross-platform pro metronome (as some use timer which is bad) 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.

rreyes1979

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 :/

OsrsNeedsf2P

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.

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/

transcriptase

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. We could call it a .exe

happyweasel

You are essentially one executable just an editor so why don't you link statically ? Apart from the c runtime?

s_ting765

There is Open Build Service from openSUSE which allows you to create packages and repos for a handful of distros. https://build.opensuse.org/

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.

ivanesmantovich

Use brew on Linux! https://www.ypsidanger.com/homebrew-is-great-on-linux/

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.

krzyk

So is this app written in Rust or in JS/TS? Why is he writting about npm at all if it is Rust? I've seen few times that people abuse npm to do install of software that is not js, but why force me to install npm?

Retr0id

Let's say I can build my software as a single static Linux binary (or at least, one for every supported arch) with no external deps outside of the syscall ABI. Which often isn't true for nontrivial software, but let's say it is. Is there some kind of automatic "make packages for everything" tool to stuff it into a .deb, .rpm, etc., and upload to the relevant package repos?

dvorka

So true - I packaged C++, C and recently Python app for Linux and it takes me so much time even if I try to automate as much as possible. I hate it. I needed to read through poor or obsolete documentation, non-existent guides and tools, do ugly tricks, use various exceptionsto make it usable/work ... and now generative AI policies and exceptions. I use Linux exclusively for ~30 years, but packaging for Windows via winget was actually much simpler:-/

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.

_benj

Uff, doing all of that plus developing your software sounds really hard! I package software for void Linux... I don't think there's an expectation from devs to know all the intricacies and particulars of each distro and contribution guidelines in order to package software for it... A tar or GitHub repo and clear instructions is all we need to package it. It becomes a pain when the software has hard dependencies on either bleeding edge unreleased software (I'm thinking hyprland) or very old versions of libs that are no longer shipped with the distro. Another pain point is when the software makes assumptions about Linux like all linunx use glibc or have systemd. In cases like that packaging software might entail patching it, or just giving up (void doesn't use systemd for example) Hope this gives you a bit of insight into what packages might be looking for