Package this tool

[Mte90]

So following sonic2kk/steamtinkerlaunch#949 a lot of things there.
I think that the best step to integrate it in STL is:

• A CI that on a new release generate a new tar.gz with the binary - ci(compile): and publish #2
• STL using the already implemented function that download the dependence automatically download it
• Integrate the tool inside STL

If you want I can work on the first 2 :-)

Step 1 done :-)

[sonic2kk]

Awesome work on this!

I did request an AppImage build as well, however, I would like to hear if you have any objections to this. Or rather, how portable is the binary going to be to most systems? As in, a system that is compatible with running Steam is already going to have various dependencies. Perhaps as you said an AppImage really isn't necessary?

I want to try and maximise compatibility, that's my main concern. And this project should really only depend on probably some C++ libs for LevelDB. The LevelDB Arch package depends on Snappy which may be missing on some systems. I believe KDE will include it for some Qt stuff but unsure if that is still the case or if we can rely on it - or if the binary will "just work" and our built LevelDB will already include this?

Maybe these are all silly, obvious questions. I have no experience with packaging and have probably already asked lots of frustratingly silly questions! 😅 But I hope it doesn't come across as deliberately being obtuse, I just want to make sure we get the right solution!

[Mte90]

So now it is enough to understand how to do an appimage with CI but I never used it if not on the steamdeck itself.

https://github.com/AppImageCrafters/appimage-builder/blob/main/.github/workflows/stable-releases.yml#L41 we can copy the CI from this to generate the appimage.

The only way to check the portability is trying to execute it in different machines, as just have very few dependencies and very simple I think that there shouldn't be any issues.
A way it is to release a new version, I will download the binary and try it on my debian sid machine and on steamos VM and we can check just 2 systems in this way and has it is compiled with ubuntu you have 3 systems.

[sonic2kk]

and has it is compiled with ubuntu you have 3 systems.

And I use Arch, so that will be 4 systems, so even better :-) (SteamOS is quite derivative of Arch especially because of the nature of the Snapshots, so pure Arch is also good to test like I have)

I could probably also set up a VM with a couple other distros, like openSUSE Tumbleweed.

I also think that while once again, I highly approve of having a dedicated binary, this manual testing of portability is one argument in favour of using an AppImage: Ideally, we can include what we need in one executable. It doesn't always work like that in practice, but for a project of this size that should only have a dependency tree of four, I think it's fine (LevelDB, which only depends on Snappy, and Snappy depends on two dependencies that Steam also requires: glibc and gcc-libs).