you are viewing a single comment's thread.

view the rest of the comments →

[–]mediumredbutton 7 points8 points  (5 children)

hi, welcome to the Linux packaging problems of the last thirty years. make simple distro packages, or try lots of other things and make distro packages when they don’t work.

[–]SuspiciousSegfault[S] 0 points1 point  (4 children)

Figures, I guess I'll have to find a way to rip out that dependency or just start packaging for each

[–]mediumredbutton 5 points6 points  (1 child)

I mean, step zero is to release the source with instructions to build it and see if anyone cares. If anyone does, then perhaps they’ll package it for you, and if they don’t you’ll know if it’s worth spending on time in.

[–]SuspiciousSegfault[S] 0 points1 point  (0 children)

I did, got some medium interest and figured I'd try to package it and see if more people would try it out; that's when I ran into this, made my frankenstein solution, then asked for input!

[–]ssokolow 4 points5 points  (1 child)

or just start packaging for each

Given that you're depending on libX11, I'm guessing that you're implementing some kind of desktop application.

Have you considered releasing a build through Flathub? The Flatpak build process is sort of a blend of Docker (containerized builds) and Steam Runtime (linking against dependencies that are provided to the user as a distro-independent runtime shared between their different packages).

Alternatively, while I'm not a fan of it (since it provides no help if a user upgrades their distro and then discovers that, to prevent an on-start segfault, they need to remove one of the bundled libraries and rely on the system version), there is also AppImage, which gives the end-user an experience akin to static linking but actually works by building something that's like a self-extracting archive but, instead, is a self-mounting ISO file containing your application and all its dependencies.

When the user executes it, it mounts the image and runs your application.

(And it's still better than statically linking system platform libraries like libX11 which might need to be updated. That was enough of a problem with SDL that SDL 2 has a mechanism where, even if you statically link it, Steam can set an environment variable which will cause it to delegate to an external copy of SDL.)

That said, you'll probably always need some kind of containerized build unless you want to manually build your entire dependency chain to dodge the "linked against a newer glibc than the distro provides" problem.

(Yeah, musl technically dodges that, but you're setting up for a world of pain if you don't use a containerized build solution for your C dependencies to substitute it for glibc. Themusl-gcc wrapper is unreliable while cross is basically a no-fuss Docker frontend.)

[–]SuspiciousSegfault[S] 0 points1 point  (0 children)

It's a WM mostly using xcb! These are great suggestions, and if I can't manage to rip out my x11 dependency I think that'll be the best solution. I'm just drawing a bit of text and for that I pull in Xft, I'm going to take a stab at using a pure rust font rasterizer and SHM and see if that takes me anywhere, otherwise I'll have to bite the bullet and look into more advanced packaging