Linux: implement relative installation

[illwieckz]

When renaming the updater with the relative string (any case) at the beginning of the name (for example relative-updater or RelativeUnvanquished), the updater installs the game in the same folder the updater executable is.

---

Original message:

When setting an empty updater.conf next to the updater executable, the folder containing the updater executable is used to install the game.

Fixes #90:

• Idea for store integration: use current directory if updater.conf exists next to updater #90

Needed by (if we want to do it):

• Distribute updater with universal zip #117

[illwieckz]

This would be useful for the Lutris store. Updating a game there is painful because any update for the game has to go through a review process, so we aren't in control and an update can be slow to get. So with time we stopped updating the game.

Such store offers the user the ability to install the game where they want to. Historically we unpacked the unizip. With such feature we would just unpack the updater and write an empty configuration file next to it, and the updater will install in the folder the user selected in Lutris. If a game was already installed in such folder, it will update the existing files.

We would only need to update the game in Lutris when we update the updater.

The updater is supposed to update itself in the same directory (not tested), so even if we are slow at updating it in Lutris, as long as the old one works, old installations will get the updated updater, and new installations will work with the old updater that will install the updated updater as part of the install process.

The bonus is that by using the updater instead of the unizip, we install the desktop file and then set up the protocol handler, while retaining the ability for lutris to install in an arbitrary place.

[illwieckz]

I flag this as draft because something doesn't work yet: the configuration file is never written, so it always consider the game to not be installed when restarting the updater.

[illwieckz]

I flag this as draft because something doesn't work yet: the configuration file is never written, so it always consider the game to not be installed when restarting the updater.

I found my mistake: I was setting the folder as config file path, instead of the file itself…

It works.

[slipher]

I don't like that if you downloaded a file named updater.conf in your downloads directory and then downloaded the updater, it would hijack the updater and make it use the download dir as the installation dir.

What if we made it based on the updater binary having a magic file name instead? I assume you could rename it in the Lutris script thing. Note that with this idea we would need to disable installUpdater to prevent the file from being renamed.

[illwieckz]

Hmmm, and what if we use an hidden file with a unexpected name like .Lxa1Y28XuoCj6Twa4x2VSIUMuRFewR30jYKY7HJyT2QuJAc? We can also put a magic value in it, like s80023qzsl6UKL6de2j1EPHMVKaBxMT5Qc8pHu66GZOQaSFp. 🫣

[illwieckz]

I implemented the renamed executable method. It works.

Every Linux executable that starts with the relative case-independent string will install relatively to the executable folder.

For example you can name it relative-updater or RelativeUnvanquishedUpdater or Relative Unvanquished Updater or just Relative Unvanquished, and the game installation will be relative (the engine and the game files are downloaded in the same folder), and the updater will preserve the updater executable name when updating itself. The desktop file now also uses the custom updater name when the installation is relative.

That makes me think that maybe in the future we may add a similar mechanism with a portable prefix that would not install any desktop file and use a home folder within the same folder the updater is (and the engine is updated), allowing people to rename the executable Portable Unvanquished or something like that and get a fully portable installation.

[slipher]

Supposing we had a portable installer, do we really need a "relative" installer too? Like is it actually necessary/desirable to install the desktop files in the Lutris case?

Maybe the UI control for editing the install path should be disabled?

FWIW there's nothing about this installation mode that's really Linux-specific. Instead of modifying the Linux makePersistentSettings, it would be possible to make it OS-independent by modifying the Settings constructor to do the executable name check and then use a relative path IniFormat settings store if it is relative, or the makePersistentSettings if not.

[illwieckz]

Supposing we had a portable installer, do we really need a "relative" installer too? Like is it actually necessary/desirable to install the desktop files in the Lutris case?

It is desirable in the lutris case to both:

• install the dekstop file and set the url handler
• use the standard home directory

Which is different than “portable”.

[slipher]

So if it's OK to integrate everything with the system as usual, why do we need relative installation at all? I read that Lutris scripts may be implemented by forwarding to other launchers such as Steam or Battle.net. I assume that those launchers install everything in their own customary locations rather than a Lutris-specified one. Is the purpose just for Lutris to tell if the game was already previously installed by seeing if the updater binary exists?