Hacker News Reader

Comment by Popegaf | Hacker News Reader

I'll go ahead and be naive here, but hasn't Linux solved the dependency issue with all their packaging formats? With a CI setup, you can have a pipeline that tests your game, builds it on multiple platforms in multiple package formats (AppImage, flatpak, snap, deb, rpm, etc.) and checks if the game will start (on CI) with headless X11 (Xvfb).

Locally, you could use vagrant to startup multiple linux distros then build and startup the game for a visual test. It would then be easier to output a list of "tested on platform/distro X,Y,Z" as well as the deps for each of them.

View on HN

Deb, rpm et al don't help here at all.

You can't use their dependencies or you'd need to provide builds for different versions of the same distro (because many many many libraries aren't that stable, and distros typically only provide one version of each).

And you probably don't want to run your own repository (and I'm not even sure apt can do repositories with a login, so you'd be making your game available to everyone with the link), so you can't use their update functionality either.

So then all you have left is a bad archive format - essentially a distro-specific .zip that's more annoying to build.

The other tools ship dependencies with the program, so they don't have this particular issue. AppImage and Flatpak are also cross-distro, while snap is tied to Canonical and awkward on other distros.

This is not really a problem for open source games with an active Debian/Fedora maintainer. If there are interested packagers and you give them source code to work with, I've noticed they will be happy to build and test your package and try to keep it updated. The point of using deb/rpm is to integrate with the distro. If you want to go directly to customers and you have no intention of tying your package to the distro release cycle and working with their package maintainers, then yes, it seems it would always be a bad fit.

For open source games, sure.

But this isn't an open source game, as far as I can see, and most games aren't.

Also I often find the fixed releases of most distros to be a bad fit for games because the stability argument matters less and less - there's little in the way of backward compatibility to keep, and hence no real reason not to upgrade.

(not that I'm much of a believer in fixed releases to begin with)

I guess that's why most games are a bad fit for trying to ship as part of an open source Linux distribution, where the requirement to get packages upstream is that they have to be open source and compatible with the distro's usage and redistribution policies.

The problem is installing a random deb, and it's dependancies, can be quite tricky. Also, you need your users to know if they need AppImage, flatpak, snap, etc. (I'm an Ubuntu user. I know it uses deb, I have no idea which of AppImage, flatpak or snap it uses).

Also, you have to keep them up to date as new distro versions are released, whereas many games work on a principle of "release, and done".

Making a release where you link as much as you can statically increases the chances it will work in the future.

I know this isn't the point of your comment but: AppImage works everywhere, including Ubuntu. It a file called TheProgram.AppImage and runs like any other binary would. Snap works primarily on Ubuntu and is pre-installed. `sudo snap install [package]` works just like `sudo apt install [package]` does. Flatpak technically works on ubuntu though it's not pre-installed: it's an `sudo apt install flatpak` away.

AppImage is a great option: it's the equivalent of statically linking everything. Users only need to have the binary and they can run it. Developers bundle everything into that binary.

To chime in: I'm super impressed by flatpak. There is a small learning curve as with any tool, but once you get through it it works very well.

Snap uses a compressed image format that makes startup horrid. And snaps don't seem to work well with hidpi resolutions when scaling is enabled (snap doesnt know about the scaling so it draws everything super small).

I haven't used AppImage but between apt, snap, and flatpak, I really see flatpak as the winner for how games should be installed.

I played with Appimages a while ago, trying to create one from scratch with a Ruby interactive shell inside. It worked well until I tried it on an older Ubuntu, it gave me glibc errors. To make it work I had to find a docker image with an old enough glibc to use as my "compiler", then copy over everything to the Appimage. I also tried compiling an older glibc from scratch inside the Appimage, that solved nothing, as well as needing to install all the binutils that I wanted to embed in the Appimage and make sure the PATH does not contain any host os paths.

It was a nice learning experience, but far from the "Easy to make, runs everywhere" marketing Appimages have.

Does using muls libc and statically linking everything actually work out in practice? I read somewhere (HN comment, don't have reference) that it still might not be enough and your programs still need to the OS libc.

Changing out glibc for musl can be done if you control the linker invocations on the object files. This would be extremely difficult (but not impossible) for those like myself that use closed-source third-party shared objects linked against glibc.

> To make it work I had to find a docker image with an old enough glibc to use as my "compiler",

it's not like it is esoteric knowledge though: https://docs.appimage.org/reference/best-practices.html#bina...

I really like AppImage and its one file = one application philosophy, but the unfortunate reality is that the distro landscape is so messed up that AppImage doesn't reliably work everywhere unless you take similar pains in building your application (old glibc, etc). Above the kernel, the Linux ecosystem just isn't designed to support the concept of binary application distribution, unless you want to maintain a separate package for every distribution you want to target and keep it up to date.

Package managers solve distros' own problems. For an outsider, it's still a massive pain.

Distros are usually tied to specific versions of libraries. Your package can't require a library that is too old or too new, because the distro won't have that version, or won't install it, because it'd conflict with other packages. The way around it is to prefer static linking, but then you're reducing the whole dependency and packaging system to just being a zip file with extra steps.

There are many package formats, and many distros with different versions. It's a PITA to set up a build farm for everything and keep it from bitrotting.

And even if you build a two dozen packages, you need to help users download the right version, and tell them how to install it (my pet peeve in many distros is that when you double-click a deb/rpm, they won't offer to install it, but browse it like a folder or treat as an unknown file).

All of this is so much more fuss than "Here's your Windows.exe, or Mac Universal.app".

Reply on news.ycombinator.com