I hate packaging my software for Linux
getfresh.dev
getfresh.dev
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.
There are Canonical PPAs for that, which make distribution much simpler (it's still not as simple as it could, but with AI's help it's simple).
If a package doesn't have particular build requirements, setting up a PPA is overall simpler than hosting a personal repo (I do both).
Thus my recommendation for aptly/reprepro: it's a more natural extension of what the project already has in place rather than a "you should do this instead."
I use fedora on my work machine. It is a pain. But hey, freedom of choice has its drawbacks too.
But from your comments, the message I get is that you want to apply to become a maintainer in each and every Linux distribution's package repositories, both mainstream and niche? And apparently also create packages for some alternative package managers too? (e.g. mise, npm, Terra)
Your users on these platforms that you don't seem to understand, aren't expecting _you_ to package your own software, they want the maintainers of their distribution to package it, as they know the distribution, which you probably don't.
Large part of the point of using distributions like Debian and Ubuntu is exactly this, that there are people deeply familiar and knowledgable about the distribution itself, who package the software and apply any needed patches, or wrangle it into what's the standard for the distribution.
When something isn't packaged for these users but they feel like it's popular/useful enough to be, they'll open a request with their distribution for someone to maintain that, in the distribution itself, so everything is aligned. Even though they're not supposed to, some users will bother you and ask you to package it for them, which isn't correct and shouldn't be like that. They either package it themselves, or ask their distribution to do it for them, as the packaging shouldn't have anything to do with the developer of the software.
Distro maintainer curation is a godsend for security and reliability. Distro maintainers and people who work with them to get things packaged are heroes. But let’s not pretend that maintainer curation is something the average user trying to run a new piece of software cares about.
You somehow seem to be under the impression that all users are the same, which evidently they're not, then we wouldn't have many distributions.
Of course, most macOS and Windows users think exactly like how you outline. But the typical Debian, Ubuntu or Arch user don't think like that, as they typically understand what kind of environment and ecosystem they're in, where they don't expect every software developer to understand every distribution.
> But let’s not pretend that maintainer curation is something the average user trying to run a new piece of software cares about.
What in my comments gave you the impression that I'm trying to argue for this at all? Of course they don't care, otherwise they'd be maintainers themselves.
You said:
> When something isn't packaged for these users but they feel like it's popular/useful enough to be, they'll open a request with their distribution for someone to maintain that
I don’t think that happens nearly often or quickly enough for most users to be satisfied. Hence why so much software is released through tertiary PPAs or .deb download links and so on.
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.
Yup, this is why I think so many people feel so much friction about it. On Windows and macOS, the developer is usually responsible for the entire thing, even shipping installers for users. Linux distributions tend to split the roles, and as mentioned, once you provide sources and how to build it, you're basically done and it's up to others now.
And if you want a system whereby software only gets made available if distro-providers care enough, then that's fine. But you're putting a filter between the software producer and non-technical users, and you should be aware that this is a choice you're making.
If nobody cares enough to make the application available, perhaps it just shouldn't be there.
And yet insane quantities of programs used by millions are only available via raw .deb file downloads, or random alternative PPAs, or via programming language package managers.
The distro maintainer system is impressive, and I’m thankful for it. But saying “it has worked for lots of packages” says nothing about the many it has not worked for.
But you're "at the distro", and you want to use it, so you package it :) You might want to be nice to others too, so you make that public. Eventually, the community might end up relying on it, and the package gets an official maintainer from the distribution itself.
I've been able to have all the nice things I've wanted, but I also sit down and learn the distributions I use, including how to package stuff, so I can do that myself for things I want to use :)
Some distributions like Arch makes this "self-packaging" extremely easy and simple, and today with LLMs I'm guessing you can get the agent to package most standard software people ship today in under 5 minutes into something acceptable for your own use.
I need a solution that works for my users regardless.
You seem to be treating this like a commercial endeavor in which you have much to gain from adoption by nontechnical people. I don't really see why though. It looks like you're developing non-commercial open source software for an audience of developers.
You are taking on the responsibility of being compatible with a large variety of different people's opinions on how software should be built, configured, and distributed. Yes that's a lot of work. Distributions have people willing to do that work for software they or their users (who can ask) care about.
The idea that your OS distro needs to explicitly support and package every software you could ever want to use seems crazy to me.
Both users and authors want the same thing: low-effort, high-quality distribution of software.
Personally I put my support behind flatpak for GUI, mise for CLI/TUI, but it's not a perfect solution and I occasionally bail out to homebrew/linuxbrew.
Somebody has to do the work. Apparently you won't accept it for that to be the developer, the user, or a "professional third party" (whatever "professional" means here). What exactly do you want?
> Personally I put my support behind flatpak for GUI, mise for CLI/TUI, but it's not a perfect solution and I occasionally bail out to homebrew/linuxbrew.
So third parties. Things that have reinvented "distributions", arguably badly. Are you saying they're not "professional"?
1. I want it to be easy for developers to publish their own packages. 2. I want it to be easy for users to install these developer-published packages.
> Are you saying they're not "professional"?
I regret using the word professional, I was replying to the claim GP made:
> Packaging it for a distro is someone else's job
Well I (as a developer) want to publish my own software without waiting and hoping someone else will do it for me.
> Somebody has to do the work.
Yes, I (the developer) want to do the work. The whole point of the article is that its painful to do today. I'm interested in how we make the packaging work easier so the developers can do it.
> [...] So third parties
the whole 3rd/1st party question is whether a developer can publish their own package. In most cases they technically can (taps, PRs, flathub, Debian registries, so on) but run into lots of issues along the way.
No one is under that impression, not maintainers nor users. The idea is that every software that is common and/or popular and/or useful enough to someone who is willing to maintain it, is managed by the distribution/repository staff itself, as they're the ones who knows the distribution best. Some software requires patches to be fully compatible, some distributions expect certain files in certain places and so on, and no one expects every developers to understand the idiosyncrasies of every distribution they want to potentially ship to.
But that doesn't mean ALL software you use has to come from these official software repositories maintained by the distribution. Most of my packages are from the official Arch repositories, maintained by people who know what they're doing extremely well, and almost gives you certain "guarantees" by the mere existence in that official registry. But then some software I use is installed via the AUR, which is more like npm, where anyone can publish anything, close review of everything is required for this, it's the wild west. And some software I install/run by having local GitHub checkouts I build binaries from. Finally some are just stray binaries in ~/bin/ that I've had for decades and don't even know where they're from anymore. All are "correct" for what purpose they serve, yet the official Arch repositories still remains extremely important and valuable for stability.
Still, the software that almost all of the distribution users use, like wayland or systemd, is maintained by these people and explicitly "supported" by the distribution, as far as that term holds in FOSS.
polishes ex-Debian Developer badge
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....
As a user that surprised me at first, but I’ve grown to really like it!
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.
It works. It works great. It's actually the only sensible solution if you want something compiled today to work without changes on both Windows and Linux in 10 years.
I did an experiment, implementing a GUI calculator, and Rust + Slint + cross-compiling to Windows (I develop on Linux) + Proton runtime was the clear winner:
- compiled bundle: 20 MB (F#/dotNet + Avalonia: 207 MB)
- loc: ~1000 (dotNet: ~700)
- dlls: none other than what Wine provides (dotNet: 67 .dll files)
Another option I considered was Zig with the Win32 API, but the LOC count was unacceptably high.
I'm working on a write-up for the experiment. The premise was: "I'm working on Linux and want to create a GUI app that will, with the build done today, continue working on Windows and Linux for the next 10 years". Steam/Proton + mostly static compilation + bundled libraries is the only solution that makes this mostly painless.
Publishing on Steam costs money: https://partner.steamgames.com/doc/gettingstarted/appfee
The full discussion about this I had with ChatGPT is here: https://klibert.pl/statics/Steam-Linux-Runtime-Stack-2026-08...
Yeah, but that's also not exactly a better user-experience for the end-user than "Download .exe, double-click to launch" or "Download .msi, finish install, run program".
Distribute your software however you want, I tend to try to make the download and install as familiar as possible to the users of the specific platforms.
Btw, even your starting prompt is guiding the model to just agree with your opening statement. You can't just roll with whatever the model says and assume the conclusion of "definitely can run in 10 years unchanged" is true.
To your point on installation: sure, but if you value it that much, just pay Valve to add you to the Steam store? And that would be the only possible solution given my constraints, all explicitly mentioned at least once in the linked conversation:
- binary produced today works
- without changes
- on both Linux and Windows
- is a GUI app
- has some dependencies
- is developed on Linux (no Windows needed)
For other constraints, it's a solution. Worth considering. That's all.
Yeah sorry, hurling huge LLM conversations at me tends to make me skim them, hope you don't mind I didn't study the conversation you had with ChatGPT in detail.
That you considered someone skimming a chat log offensive yet the act of sharing those chat logs and expecting others to dredge through them, is almost offensive to me. So I guess we can call it even now.
> For this set of constrains, Proton/Wine with a cross-compiled Win32 binary/bundle is literally the only solution (care to name another?)
Cross-compiling the good old way, with a Linux VM, Windows VM and a macOS host (maybe Mac Mini?). I basically have the very same requirements (+ macOS), except zero third party dependencies, and end up doing it this way, all managed with Nix so basically all the installation-bloatyness is something I deal with so users get the exact same experience they expect on their OS.
The context was how to distribute software to Linux users. Not how Linux users could run Windows software.
Better yet, build it for Windows 95, and it'll not only run under Windows, Linux, and macOS, but you can even package it to run in a browser[1].
For command-line programs, you might try something like Cosmopoliton[2] instead.
[1] https://www.pcjs.org/software/pcx86/sys/windows/win95/4.00.9...
However, Steam Runtime for Linux was still in beta, last I checked. Plus, it doesn't solve the cross-platform part. But for Linux-native development, Steam Runtime might be what's needed to have long-term compatibility for apps (finally).
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.
It could be useful if updating is a pain point.
In this case, they may also consider Podman, as it has excellent systemd integration[1] including rudimentary container orchestration and the ability to auto-update containers and Kubernetes-style pods installed as systemd units. I've run Pihole under Fedora CoreOS this way for several years without touching a single thing to update the OS or Pihole.
[1] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
TL; DR you're right. We are aware options like Podman and systemd-nspawn (check it out if you don't know). They are just overkill.
If you don't need the layers of Docker and server pull-push, it is just overhead. We just fetch a single cryptographically signed squashfs file and execute the program in it with limited FS and separate namespaces.
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.
I also echo some of the comments here saying it's entirely reasonable for a single maintainer not to support absolutely every single distro unless it's straightforward or enjoyable.
Sure, you won't get into the official repos that way, but do your users really care? Fedora users are pretty used to enabling Copr and RPMFusion, Ubuntu has its PPAs. It's not ideal, but it's good enough. Even an RPM/DEB via Github release would already be a good start.
You can easily setup a copr repo for this to solve the auto update qualms for almost all the RPM repos. Needs a spec file and that's about it.
AUR should do.
Debian. Eeshk.
Being responsive to maintainers doesn't help if maintainers never reach out or even actively refuse to package your software.
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.
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.
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.
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.
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 :)
If I’m going to take on maintenance burden then I might as well make it how I want with a fork and take the notoriety.
Nothing at all. This is not stealing. The term is "forking." It's how GCC got un-stagnated (see egcs), and how we got the ecosystem of alternate wifi firmware (two examples that come readily to mind.)
This is also where Free and Open source diverge: Open Source lets someone block others from forking their fork, whereas Free Software requires that forks remain free to be forked themselves.
This is the same tired nonsense hearsay that all the people who got in FOSS as a religion and don't really understand the licensing. The licenses that OSI and FSF approve as FOSS are literally the same and they have to guarantee the same freedoms. OSI is just nicer with industry and have actual professional leadership.
Source available and fair source licenses aren't seen "kosher" by either party.
OSI vs FSF has nothing to do with the point at hand.
The BSD license permits making proprietary forks. The GPL does not. Those are examples of the distinction between "open source" and "free software."
> people who got in FOSS as a religion
Oh no! Not religion!
This is a ad-hominem argument based on anti-religious bigotry.
> don't really understand the licensing.
Again ad-hominem.
Quoth Wikipedia [1]
> Free software, libre software, libreware sometimes known as freedom-respecting software is computer software distributed under open-source licenses that allow users to run the software for any purpose as well as to study, change, and distribute it and any adapted versions.
> [...] Computer programs are deemed "free" if they give end-users (not just the developer) ultimate control over the software and, subsequently, over their devices.
> The right to study and modify a computer program entails that the source code—the preferred format for making changes—be made available to users of that program.
[1] https://en.wikipedia.org/wiki/Free_software
The requirement that those distributing the software give to their users the same rights given to themselves is the defining distinction between open source & free software.
The FSF and OSI both disagree with you.
The old BSD 4-clause is a FSF approved Free Software License. It is not an OSI-approved Open Source License (because of the advertising clause.) The newer 2- and 3-clause BSD licenses and the GPL are all both FSF Free Software and OSI Open Source licenses. What they do demonstrate is the distinction the FSF makes between copyleft Free Software licenses (which the GPL is), and non-copyleft Free Software licenses (which the BSD Licenses are)
But Free Software and Open Source are almost identical.
But, despite being a non-sequitur, I believe your statement in correct.
https://opensource.com/article/17/11/open-source-or-free-sof...
https://www.gnu.org/philosophy/open-source-misses-the-point....
Thanks for the explanation. I'll have to find a more accurate term for what I was trying to articulate, once I've dug into things more.
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.
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.
What I was talking about was the setup required on your machine/CI to get the dependencies to build those DLLs.
Only thing you ship with your application are the libraries specific to your app. If you use Qt, you ship Qt libraries as bundled DLLs. If you use Havok physics engine, you ship that as a bundled DLL.
MSI can trigger things like installing optional Windows components but it is not a package ecosystem like apt or dnf. It is more like dpkg or rpm.
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.
I don't think this is entirely accurate and in fact, I think you'll encounter limitations in how big the .exe could actually be, before the OS says no, compared to Linux or macOS where you can pack more into it. But still, on all platforms, you won't have multi-GB binaries, you have external resources which among them are DLLs and whatever, and the binary ("executable") itself ends up some MBs. At least most (if not all) of the large professional software I use on Windows is packaged like that.
What are you making?
If you need somewhat Linux-like build infrastructure, conan is very helpful to install all your dependencies and to create deployment packages.
Additionally, the Windows dynamic loader doesn't squish all DLLs into one global namespace like the Linux one does. Every time you call a function from a DLL there is extra friction, even for the programmer.
There's also the libc linking problem. Each DLL may get its own copy for libc, either because they are statically linked or because they are compiled with different versions. If you try to fopen in one DLL and fclose in another, or malloc in one and free in another, it's liable to crash. This might've been solved in the 20 years since I learned about it, though.
Win32 and CRT (libc) is shared among programs, .NET framework DLLs are also shared. Industrial software does ship multiple .exes that depend on the same subset of DLLs. Anything that uses registered COM interfaces also use shared pages for the DLLs in memory.
> Additionally, the Windows dynamic loader doesn't squish all DLLs into one global namespace like the Linux one does. Every time you call a function from a DLL there is extra friction, even for the programmer.
This is an advantage of Windows over Linux where those squish into one unified namespace create compatibility problems and force the programmer to compile everything as a one single big universe / distro. It basically makes long-term backwards compat impossible.
Compile-time linked DLLs have no significant overhead compared to Linux after they are loaded and the loader has done its relocation work.
> There's also the libc linking problem. Each DLL may get its own copy for libc, either because they are statically linked or because they are compiled with different versions. If you try to fopen in one DLL and fclose in another, or malloc in one and free in another, it's liable to crash. This might've been solved in the 20 years since I learned about it, though.
This still kinda exists. However, Microsoft hasn't broken their CRT ABI since 2015. It is a feature not a bug IMO. All properly made libraries ship their own allocation and free functions for this very reason. It is not specific to Windows. This does happen with Linux shared libraries when they use their custom allocators. Giving up the ability to link with different libc versions, ability to link with multiple versions of the same library or good backwards compatibility is not a good tradeoff just to have a single global `malloc / free` call.
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 :)
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!
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`.
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.
Mozilla can, because they are so large they can have people spend their days working on it. No one else should.
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
Quick feature set of interest to your project:
• It's free for open source projects.
• It's a tool not a service so you can just download+go without even needing to sign up for an account.
• It can create signed, self updating Windows, Mac and Debian packages in one go, with a single run on any chosen host platform. So you can ship from Linux to Win/Mac without having those systems.
• Fully supports code signing, delta updates, other advanced stuff.
• Creates a nice download HTML page that detects the user's OS and CPU etc.
• Simple config file syntax.
Check it out, see if you like it.
Albeit, the support for pure CLI apps on Windows/macOS isn't as strong as for GUI apps. There's an internal feature that isn't documented that's useful for it - it bundles a little GUI with a button that adds it to the user's path, and let's you trigger the self-update flow. We should expose that more obviously as a feature, although the incentive is low as most people distributing CLI apps and servers aren't paying customers.
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?
The "npm distribution method" is for people who already have npm installed, just like apt-get instructions are for people on Debian/Ubuntu, you're not meant to install apt if you happen to be on CentOS, just like you're not supposed to install npm if there is a better installation method for you. Sucks when it's the only installation method, same with curl|bash, I tend to just close the page when that's apparent, haven't missed anything so far.
And I find building app myself usually the easiest one.
And now today, we have a lot of new packages mangers on top of that, which has increased complexity a lot.
If I wanted to publish tools/programs, I would distribute the source code and let each distro decide how/if they want to package it. I would not try to do this myself. It's not a reasonable thing to do.
Prior to Linux, autotools was a standardization that made installation easy across the many commercial Unix variants.
That’s now moved on. There are dozens of packaging and distribution formats, none of which is universally applicable (as the OP says). And users’ expectations have moved well beyond the autotools invocation.
It’d be great for both end users and application developers for a universal solution to emerge, but there’s no sign of it happening.
To argue the other way, I guess some of it is arbitrary repository rules. Package maintainers for cadence releases don't just push the latest updates, security updates get back ported, etc. And the DIY approach of the AUR/NPM/p PyPI is occasionally a burning tyre fire of security issues or just shitty duplication and name collisions.
You could argue we should all be on layered immutable distributions but the userland layer (flatpak, Appimage, snap) isn't without complication.
So I guess everything is fine?
right now its a total mess both for users and developers. IIRC apps cant register a command line alias that gets added to your PATH and theres no way to request permissions for a file by name (you have to open a file select dialog scoped to a directory). i dont know if you can even tell the runtime to open your app in a terminal without hacks.
its all pushing devs to opt out of sandboxing as much as possible which defeats the whole purpose of containers.
./configure
make
sudo make install- 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
If your package is FOSS, having the distros ship it is arguably the easiest approach.
But not for most people.
(and compiling and installing those dependencies)
Also, once you have a functioning build using Nix, you can easily generate .deb packages with it. Nix is also fairly low maintenance, although it can be a lot of upfront work depending on the project.
Just ship a statically compiled binary for each kernel/cpu (eg: linux/and64, linux/arm64).
That’s what terraform and kubectl do, for example.
It is hopeless. There is a reason why systemd-resolved exists and there is a good reason why people say that only way to sanely interact with a Go program is through a network socket.
We could call it a .exe
But the discussion here is more about how to package properly an application (for updates, app centralized management etc,) than how to deliver an executable on linux.