Linux users: Request for information and feedback

[redeyesofnight]

Hello everyone!

Ryan here, and lately I've been working on our native Linux build of FGU.
First, I'm not a native Linux user (or at least not in 15 years), so I'd rather defer to the community on the average/expected user experience.
I've got a few questions I'd love your input on.
FYI: We are targeting Ubuntu primarily (with other Debian systems as secondary), as that is expected to be the highest install platform. We'd like to get it working on as many distros as possible, but we had to pick something as our lead.

1) What is the expected experience for installing our software?

On Windows and OSX, we've provided installers that can be downloaded from Fantasygrounds.com as a standalone package, but my personal experience with Linux/Ubuntu has been installing via a package manager such as apt-get.
Through my research, I've seen that this may largely depend on the GUI package you're using rather than the distro, but obviously we'd like something compatible with as many distros as possible, so I'd love your input.

2) What are the expected "default" installation/data directories.

On Windows, we install to C:/Program Files/SmiteWorks/Fantasy Grounds, and on OSX we install to /Applications/SmiteWorks/Fantasy Grounds. I'd love to know what the expected installation path(s) are.
At the moment, the application is located at /usr/share/SmiteWorks/Fantasy Grounds, while the data (including modules, campaigns, etc) is located at ~/SmiteWorks/Fantasy Grounds. Do these seem like appropriate paths?

3) What is the expected procedure for elevating permissions?

On Windows and OSX, special permissions are needed for Fantasy Grounds to write to the program folders (C:/Program Files/SmiteWorks/Fantasy Grounds and /Applications/SmiteWorks/Fantasy Grounds). By default, we are able to set the requested permissions and prompt the user for admin access with the program, after which our program can write updated files from our update server.

On Linux, I'm aware of the 'sudo' command to elevate access for a program, but it seems unintuitive to me to have to launch a Terminal, then do something like "sudo open /usr/share/SmiteWorks/Fantasy Grounds/FantasyGrounds.x86_64". I'd much prefer to be able to launch the Fantasy Grounds updater via UI (double clicking in folder or a shortcut) and having the system prompt the user for an admin password automatically.

Mostly looking for direction on the expected behaviour of our software, so any feedback would be great!

Thanks!
--Ryan-

[notrealdan]

1. You could maintain a repository/PPA for packages. Then users add your PPA to their package manager and are able to install packages and updates from there. Updates for FG itself should come the same way, not something like the FG updater, IMO. You'd still most likely need the FG updater (or similar) to handle fetching and updating DLC.
https://itsfoss.com/ppa-guide/

3. There used to be gksu for gui support for sudo, but that's gone now. Check out this article for some alternatives:
https://itsfoss.com/gksu-replacement-ubuntu/
I believe PolicyKit is where you would want to look. Here's the man page (also linked from that article):
https://manpages.ubuntu.com/manpages.../polkit.8.html

[Ikael]

I haven't been Linux person for some time, but here we go

1) Since you focus on delivering on Ubuntu and Debian, personally I would expect to be able to download .deb file from Smiteworks website that does the installation for me. Please note that I love package manager, but don't feel like Fantasy Grounds needs it in the first phase.

2) I have no objections except avoid upper case and white-spaces in directories and filenames. There are no real reason, just preference.

3) Do you actually need sudo after installation is done? Could you just define user (or user group) that owns Fantasy Grounds directories and application is run as that user?

[ddavison]

1. You could maintain a repository/PPA for packages. Then users add your PPA to their package manager and are able to install packages and updates from there. Updates for FG itself should come the same way, not something like the FG updater, IMO. You'd still most likely need the FG updater (or similar) to handle fetching and updating DLC.
https://itsfoss.com/ppa-guide/

The Updater is still needed for DLC and for authenticating & downloading purchases.

[notrealdan]

The Updater is still needed for DLC and for authenticating & downloading purchases.

Yes, I figured and that’s what I meant.

[wndrngdru]

A common practice for programs not packaged by the distribution is to put all the system-wide stuff inside a folder in /opt, e.g. /opt/fantasygrounds. The rest of the folders for mods, extensions, vault, etc. would live inside user's home folder.

That said, there's nothing wrong with putting it all inside the user's home folder either. That just means each user on that system would need to install their own copy. To keep from cluttering home, I would put it inside a hidden folder. Hidden folders just have a period at the beginning of the folder name, i.e., /home/$USER/.SmiteWorks

Ideally, as notrealdan said, it would be installable via PPA. Most people who run Ubuntu-based systems would be familiar with adding a PPA to their software manager.

There several pluses to doing that.

• The package manager would handle asking for credentials in cases of program updates, DLC updates shouldn't need escalation if they are saved within user folders.
• The program itself would be updated whenever the rest of the system is updated.
• It's available to all users on that system (license info would be saved to each user's home directory, users without would just get the demo).
• Software dependencies can be confirmed/installed prior to installation (this is more a function of the dpkg system than PPA).

The down-sides to doing that, off the top of my head:

• Depending system update settings, the program may be updated before the user wants it to be.
• The program would need be updated separately from the DLC (I would think, at least for starters, this could be handled with a simple prompt to update their system if not already updated)
• It's another piece of infrastructure y'all would need to maintain.

[notrealdan]

The package manager would handle asking for credentials in cases of program updates, DLC updates shouldn't need escalation if they are saved within user folders.

Oh yes, I hadn’t thought about that. It’s unlikely that FG itself (or the FG updater) would ever need escalation if the system’s package manager is handling program updates instead and DLC is stored in the user’s home directory. I bet that maintaining a PPA would be far easier than handling privilege escalation. SmiteWorks already hosts https servers anyways.

[Mellock]

As an alternative to a PPA, you may look into snap (or flatpak)? I'm more of a regular user of Ubuntu than a power user, but snaps have been gaining traction on Ubuntu (it's Canonical's thing). The website is https://snapcraft.io/

[pollux]

1) What is the expected experience for installing our software?

I myself tend to use Steam to install FG on Linux, though I doubt I'm universal in that regard. Beyond that, there are unfortunately a multitude of answers. The choices affect your update/upgrade options, though:

• Shipping FG as a deb and using apt to install is a perfectly normal way to ship desktop software. It does mean that you'll ALSO have to ship an rpm if you want to support Fedora and other rpm-based distros... which is more packaging work for you. If you do this... you really really should NOT use the FG Updater to mess with things owned by the deb/rpm. Instead, you'd commit to shipping software on Linux via deb/rpm and let apt/yum/dnf handle the updates for you. I suspect that the content system makes this approach a non-starter for you. Unless it's easy to have the Smiteworks updater separate program updates from content updates, and to delegate the program updates to apt, and then perform only the content updates, license validation, and downloading content to the data dir would would be in the linux users $HOME and require no elevated permissions. That sounds like a lot of Linux-only customization, but maybe it's simpler than it sounds.
• Snap and Flatpak are cross-distro packaging formats, but they have the same disadvantages in terms of providing their own update system that opting out of violates user expectations. Also they have restrictive security models that can be finicky to deal with, especially for graphical apps. I think I wouldn't recommend this given that you're a small company with limited resources to spend on debugging Linux packaging issues.
• I suspect this means that a tarball or other proprietary installer remains the sensible thing to do moving forward because it gives you full and granular control over content updates without getting in the way or your current updating tools, which no other system does.

2) What are the expected "default" installation/data directories.

I've learned a great deal by consulting the Filesystem Heirarchy Standard published by the Linux Foundation. All major distros abide by this standard, and it clarifies a lot of Linux/Unix "lore" about where things go and why.

• https://en.wikipedia.org/wiki/Filesy...archy_Standard
• https://wiki.linuxfoundation.org/lsb/fhs

Though maybe you should just ignore all that and install to the homedir, more info below.

3) What is the expected procedure for elevating permissions?

For graphical standards, I would look to the freedesktop.org project generally, and for graphical "sudo" I believe polkit is the most standardized thing, though I haven't used it myself: https://gitlab.freedesktop.org/polkit/polkit/. There are command-line tools like gksudo, but I believe that they tend to be specific to each desktop environment and that multiple distros support multiple desktop envs. Again, I don't have deep experience here, though.

I would strongly consider installing to home by default, though. I only ever see apt/yum/dnf being used as the tools to manage installations when they're performed to system locations like /usr/lib/ and /usr/bin/. Vendor installers do sometimes put things in /usr/local/ or /opt/, but in those cases they tend to be run-once command-line installers that execute under sudo, or they require the target-dir to be pre-chowned to some non-root user. I can't ever remember using a piece of software in Linux that prompted me with a graphical privilege elevation prompt so a graphical vendor installer could update stuff in system-owned locations. 99% of users, including linux users, are single-user systems. If you install to ~/.smiteworks/ by default you sidestep all the permissions questions entirely. And if your basedir is configurable, then maybe people who want to install to /opt/smiteworks/ can do so at the cost of having to figure out privilege escalation. I suspect this will be a rare request, though. Per-user installs of desktop software is not all that weird.

Here's a pretty well-considered and detailed writeup of one approach to installing software to a homedir: https://nullprogram.com/blog/2017/06/19/

[Moon Wizard]

As mentioned by Doug earlier, other than initial installer, I doubt we'll be able to use any of the standard Linux distribution methods. We have to run our own update program in order to deliver purchased content. However, I will have Ryan review all the options before deciding how we will deliver installer and update program.

Regards,
JPG