>>1270
Nothing Linus is talking about is really Debian-specific when you get down to it, it's just kind of a wide issue with the Linux desktop where there's no easy answer to how you get your app in people's hands. Linus figured Valve would do static-linking, but the reality was actually just that they included a local runtime of all the libraries that games would usually need, and for the API-stable ones, it also inherits newer versions from the host system when possible. This works pretty well. And then you also have the option to run a game inside a container if there still is something wrong with the host.
But Valve's solution isn't a one-size-fits-all either because their runtime is specifically designed for games, it's exactly what you need if you have a Linux storefront, but there's still a problem when you're trying to distribute your app independently. And these days, you really have four options.
- Flatpak
- Snap
- AppImage
- Native packaging
All except the last are just really space-inefficient, and that's the main downside. Snaps also have a serious performance hit. And with Snaps and Flatpaks, you have to actually work within a sandbox too, and declare what permissions your app needs along with which paths it needs to access. It's a lot more complicated than just giving someone a binary. Both Flatpaks and Snaps will probably require you to depend on specific runtimes that are available, and you'll still have to port them to newer runtime versions. The general impression I've gotten from people that have had to create and maintain Snaps is that it actually takes way more effort than even creating native packages. Flatpaks are better, and distributing through Flathub seems to be the direction that most developers are taking, but it's still not perfect. There's still a major issue with integration, for instance, the Steam Flatpak has entirely different paths than the regular package, so it invalidates a lot of documentation and it breaks any scripts that generally assume Steam is at ~/.steam/.
AppImages are probably the easiest option for distribution in most cases, and this is what RPCS3 does for instance, but this means that you can't just host a repository and push new versions there and have a piece of software update it, you have to bake the updater into your application. They also just integrate really poorly, since it's not trivial to include them as a shortcut in your start menu.
All together, this is why a lot of places still just have an Apt repo instead of bothering with other solutions. It's not that much work to just support the latest Ubuntu LTS and the latest Debian version, their libraries are generally recent enough, and it's something that has really mature tooling and documentation, along with offering the best performance and integration. Using shared system libraries means a lot less work on your part too, with respect to rebuilding when a library has a security patch or something along those lines.
