Accessing sourceports from Snap package

[Leaguesman]

Hi, just having some issues with using the provided Snap package for Linux.

I'm using Manjaro (an Arch derivative distro), and installing the snap daemon and SSGL package is fine, and runs without issue. However, I then need to point SSGL at my GZDoom installation, which is handled via my package manager, and installed to /usr/bin/gzdoom.

However, Snap packages are generally forbidden from accessing binaries on the host system. So gzdoom does not even appear in the file browser when trying to select my sourceport location.

Any other suggestions? I've not really used Snap packages before, so I may just be missing something very obvious.

[FreaKzero]

Oh ... thats something i didnt know - im really sorry about his 😞

Yeah my Problem is that i cant test this stuff on Linux myself (Testing myself on MacOS/Win10 before every release and i have a few other Alphatesters on Discord for this also) - my knowledge about CURRENT Packagesystems on Linux Desktop Distros is non existent mostly used Linux on Servers (pure Debian Systems) - and as it seems the guy who normally tests on Linux didnt Test at all.

I just used Snap because it was recommended but as i said i didnt know that Snap Packages are leveled "so low" what Rights belong.

Do you know if thats "normal" that Snap Packages cant do this ? Or is just my Building Pipeline somehow fucked up that this doesnt work ? (Just read that Snaps are "designed" to run in their own confined Space, sorry i shouldve read that before setting up my Pipeline.

Otherwise - with my Current Pipeline im Able to build the following stuff:

AppImage, snap, deb, rpm, freebsd, pacman, p5p, apk

What would be the Most Compatible/widely used Package Build for Linux distros besides of Snap for Doom Gamers ?

THANK YOU VERY MUCH - for reporting this directly here before i started the official Beta Phase 🙏 - i try to solve this as soon as possible and im sorry for the inconvenience since you installed SNAP just for SSGL. :/

[Leaguesman]

No need to worry, it is an alpha after all.

So, as far as software distribution on Linux, there's the traditional model of distribution-specific packaging (deb, rpm, pacman as examples from your list). As a non-native Linux user you probably don't want to use these, as you wouldn't really have the capacity to target and test these different packaging systems.

The new model that's trending is distribution agnostic packaging. The three standards available here are AppImage, Snap and Flatpak. These are designed to provide packages that work on (nearly) every distribution, as a means to provide developers like yourself with a single target for build.

They each have their strengths and weaknesses, but in your specific case I would recommend AppImage. Mainly because;

1. Sandboxing is not forced; this is the issue I was running into with your Snap package.
2. It's the closest thing to what you're used to working with; functionally speaking it's nearly identical to a dmg or .app on MacOS, or an exe on Windows.

The only thing with AppImages is that there's no inbuilt auto update mechanism. I'm not sure how you're thinking of handling updates for SSGL in future, as to whether this would be a dealbreaker or not. From my understanding of the format, developers can implement their own auto-updating feature in an AppImage, similar to how a lot of Windows applications handle updates.

Some related reading you might find useful; Comparison of distro-agnostic package formates Another comparison

[FreaKzero]

Thank you so much for the detailed information. I knew about the distribution-specific packages and that i didnt want to use them - but didnt know that there are so many agnostic Packagers right now.

And yeah since i can pretty much build AppImage out of the Box with the GitHub CI Setup i have, i will go this route. Sounds also from the Articles you gave me as the most practical.

What Autoupdating belongs - Electron itself has an Autoupdate Mechanism but i would have to buy Certificates out of my own Pocket to do this on ALL Operating Systems (Apple...) - so that will not be a thing for the upcoming Future.

Thank you!

[FreaKzero]

FYI: Just prepared everything to package it now in AppImage format, if its not too much to ask - i will inform you when im able again to build (right now GitHub CI globally is broken https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/m-p/38003#M3184) so you can Test it finally out.

[FreaKzero]

@Leaguesman AppImage is now Available from the Pipeline here: https://github.com/FreaKzero/ssgl-doom-launcher/releases/tag/v2.0.0-devpreview.21

[Leaguesman]

Appreciate all the hard work. The new AppImage release works much better. Tested with two different sourceports, and a couple of different groupings of WADs, no issues with loading binaries or files.

I'm looking into compiling and testing the Oblige support, but consider the issue resolved.