Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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
by _benj - > 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.
by pmontra - mozilla hosts an apt repository for firefox, I much prefer using the native package managementby Palomides
- Giving software the rights to overwrite itself is not good design.
Mozilla can, because they are so large they can have people spend their days working on it. No one else should.
by xorcist - 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.
by s20n - You're trying to force Linux-style packaging where declaratively specified dependencies from a single(-ish) repository and shared DLLs are a necessity due to intentionally hostile architecture of GNU/Linux for shipping binary-only software. You have to build everything as one single OS, because that's how Unix people did in 80s. Unix people weren't designing an OS for general binary software distribution.
You need to give up Linux-style thinking first. Windows-native tools like Visual Studio, WiX, MSI etc. make it nice and easy to vendor your own DLLs. They are designed for closed-source and binary-distribution first. And if the libraries are designed for this ecosystem, you just import them in VS.
If you don't want to give up Linux-style dependency management you can use source-based build systems. You can use `conan` as a source package manager to get something closer and then export every single binary dependency `conan install . --deploy=runtime_deploy --output-folder=dist`.
by okanat - I always assumed those were statically linked into the binary or installer or something on Windows. Are people pulling down dependencies through the .msi?by nemomarx
- You seem to be assuming building for Windows in a Linux-like flow. If Linux is a series of tubes, Windows is a truck. On Windows, you build the library and statically link it to your executable. The executable is one big monolith that doesn't get cut up into miniscule pieces like on Linux. If you really need a DLL for some reason, you use as few as possible, and put it right next to the executable. On Windows, binary artifacts are "heavy".
Of course this assumes your main product is an executable - if you're intentionally shipping a COM object or something, which is a DLL, different guidelines may apply. In that case you should still ship a "heavy" single-DLL COM object.
by inigyou - > 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)?
The only sane way I've found to do this, is ensuring I never package it on a personal computer/computer with state, always a CI worker with fresh everything, isolated from everything else, with nothing assumed. Then for the packaging, define all required dependencies up front, and you won't end up with the typical "oh, I forgot to ship/package lib X and I didn't get any errors because I have it installed". Helps to set all this up with Nix too, can help you manage the VM lifecycle, and makes reproducible cross-platform a lot easier :)
- 99% of applications on Windows will just include all their dependencies in a folder with the exe. It’s great — it works, it’s compatible, it’s simple!
Getting dependencies to build your app is definitely harder on Windows but the fact that you can just throw things in a folder for a binary distribution is unbeat!
by lpghatguy - 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.
by OsrsNeedsf2P - 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.by snarfy
- This, exactly. It's not a developer's job to package their code for every imaginable distro; it's their job to make the build process as simple as possible and let maintainers and users handle the packaging if they want the software. The time spent chasing down the hassles in the post would be better spent thinning the dependencies, if that's remotely feasible.by zopa
- There is Open Build Service from openSUSE which allows you to create packages and repos for a handful of distros. https://build.opensuse.org/by s_ting765
- 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.
by rock_artist - 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 :)
- 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.
by xorcist - Fully agree. In good 'ol times, we had (and still can have!) GNU Autotools where the maintainer created distributions and the end user's (packager) system just needed to have rudimentary support for building programs from source (POSIX-compliant make, shell, compiler, linker etc.).
I know, speaking for GNU Autotools will get me downvotes and nasty comments, but there are many things the GNU Operating System got right and stable, mature distributions like Debian show still its heritage.
by smartmic - 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?by _sinelaw_
- > Is a self updating static binary a reasonable solution?
It's a reasonable antidote against DLL hell, so I would say yes, that's as close to an ideal solution as we can get.
by Shorel - 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!
by jdc-pub - 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.
by okanat - Linus Torvalds has talked about this very issue. He didn’t even release his own app for Linux as a result and relied on others to pick up the slack and package the app for Linux, while telling them they were wasting their life.by al_borland
- I personally think that a self-updating static binary is the pragmatic choice. I give out my software in the form of a single static binary which my users can update using a simple "update" command when a new released is published - they also receive access to the Git repo if they for any reason choose to build it themselves. I've had users on many different Linux distributions and no one has complained yet.by GOATS-
- Usually thats the job of the Distro maintainers, your job is to provide a .tar.gz site on your website, the distro maintainers are responsible for publishing your app on their distro's.by theknarf
- The answer is to not do it. Provide the source and help distro maintainers to package it for you. You can help by being responsive to maintainers' questions, making sure the source is clean (no binary blobs, weird licenses, strange build systems, generally builds like similar packages), and integrating patches from maintainers upstream.by rwmj
- I am a solo developer of a niche CLI application. The use-case is backing up your computer data to S3 Glacier (cold storage) and later restoring from it.
I took two actions to distribute my app.
First, I automatically build static binaries for Windows, macOS, and Linux: https://gitlab.com/philipmw/warmup-s3-archives/-/releases/v1... . This part is fully within my control, and I believe these binaries fully cover the potential audience. This works well because my app is just one binary, so I am not worrying about distributing assets or other complications. If you like this, adopt my `.gitlab-ci.yml`.
Second, I am already a Nixpkgs contributor, and I added my package to Nixpkgs. Nixpkgs is niche in its own way (as you point out too), but it makes it trivial to adopt my app if you're already using Nixpkgs. Given that my app's intended audience is very tech-savvy, Nixpkgs is probably a good fit here.
by pmw - 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.
by jorams - > You provide sources and instructions on how to build them
Have you ever interacted with actual users? This is absolute no-go which will only bring world of pain on you and your issues list and your email and your Discord and whatever other way you decide to talk to users....
by general1465 - "Someone else's job" doesn't help getting the software into my user's hands.
I need a solution that works for my users regardless.
by _sinelaw_