New Linux AppImage and source builds to test

[mcarans]

"ARGV0 provides information how the AppImage was called. When you call an AppImage through a symlink for instance, you can get the path to this symlink through ARGV0, while APPIMAGE would contain the absolute path to the file behind that symlink."

That sounds like it could solve the problem. What do you think?

From where I'm sitting, that sounds like the cleanest way to give old installer users a simple-ish workaround during the 'test phase', short of my proposed patch to the wrapper script which would be invisible to them and require no action.

Further... Could it be a fairly good idea to get the Appimage to drop stuff (if not already existent) into ~/.local to cause apps menu items to be created in a similar way to the installer? I'd suggest avoiding clashes with existing filenames from installers etc., and to ensure apps menu titles appear different so the testers know which they're launching. Perhaps it could appear as "Oolite (Appimage)", rather than "Oolite (oolite.space)".

Great work! Wish I had time at the moment to get properly re-immersed.

Please see if this appimage works with symlinks if you have time: https://github.com/mcarans/oolite/actio ... 4949452794. It uses ARGV0.

I'm investigating various appimage related tools that might cover some of the suggestions you've made.

[MrFlibble]

Please see if this appimage works with symlinks if you have time: https://github.com/mcarans/oolite/actio ... 4949452794. It uses ARGV0.

I'm investigating various appimage related tools that might cover some of the suggestions you've made.

That works, as long as the symlink is being executed at ~/GNUstep/Applications/Oolite.

Code: Select all

$ cd ~/GNUstep/Applications/Oolite
$ ln -s ../../../Downloads/Oolite_test_1.91.0.7738-251223-46d0fcb-x86_64.AppImage oolite.appimage
$ cd /tmp
$ ~/GNUstep/Applications/Oolite/oolite.appimage
# Success. Selecting my savegame shows my custom D.T.T. Warlance.

Of course that still won't address running via a symlink elsewhere, e.g. ~/.local/bin, a normal $PATH location. To achieve that with this method still requires a wrapper script.

APPIMAGE returns the "(Absolute) path to AppImage file (with symlinks resolved)"

If that were true, it might be that APPIMAGE is the better solution. However, here I show testing that (with the (previous appimage) in ~/GNUstep/Applications/Oolite, with a symlink in ~/.local/bin

Code: Select all

$ cd ~/.local/bin
$ ln -s ../../GNUstep/Applications/Oolite/Oolite_test_1.91.0.7728-251219-7857806-x86_64.AppImage oolite.appimage
$ cd /tmp
# User convenience: We can call it without path from anywhere as ~/.local/bin is in $PATH
$ oolite.appimage

# Select savefile. See that the OXP ship is replaced with a question mark.

$ grep load.failed  ~/.Oolite/Logs/Latest.log 
11:06:03.349 [load.failed]: ***** Failed to load saved game "Flibble-Z4-20251221-003.oolite-save": Could not find ship type “dtt_war_lance_player” - please reinstall the appropriate OXP.

So that's not working as expected. If it did, then dropping the appimage file in ~/GNUstep/Applications/Oolite and sym-linking from somewhere in $PATH would result in OX[PZ]s being found in ~/GNUstep/Applications/Oolite/AddOns.

I note that command line arguments are passed through to oolite. I've not dived into appimage or your methods, but would guess that the legacy wrapper scripts which launch the oolite binary still exist in some form. If APPIIMAGE cannot work, would it be particularly hard to add the one-liner I'd suggested suggested yesterday into those scripts. A positive test could warn about upcoming deprecation as well as changing $pwd to work around this issue. Maybe add a 'custom OXP paths' command line option.

OT: I found that running with a garbage argument (I mistyped --help as --helo) is simply ignored, so Oolite launches fully. Perhaps for unrecognised command line arguments Oolite should spit out the help text then exit.

In legacy, the script ~/GNUstep/Applications/Oolite/oolite checks for first run, shows a couple if file if so, touches a file to say they've been seen, and then runs ~/GNUstep/Applications/Oolite/oolite.app/oolite-wrapper which in turn contains the lines:-

Code: Select all

OOLITE_ROOT=$(cd $(dirname $0); cd ..; pwd -P)

# and later...

cd ${OOLITE_ROOT}/
./oolite.app/oolite "$@"
RC=$?

Perhaps these stanzas (if they exist in similar form in your appimage) might be the source of some confusion.

[mcarans]

That works, as long as the symlink is being executed at ~/GNUstep/Applications/Oolite.

Code: Select all

$ cd ~/GNUstep/Applications/Oolite
$ ln -s ../../../Downloads/Oolite_test_1.91.0.7738-251223-46d0fcb-x86_64.AppImage oolite.appimage
$ cd /tmp
$ ~/GNUstep/Applications/Oolite/oolite.appimage
# Success. Selecting my savegame shows my custom D.T.T. Warlance.

Of course that still won't address running via a symlink elsewhere, e.g. ~/.local/bin, a normal $PATH location. To achieve that with this method still requires a wrapper script.

APPIMAGE returns the "(Absolute) path to AppImage file (with symlinks resolved)"

If that were true, it might be that APPIMAGE is the better solution. However, here I show testing that (with the (previous appimage) in ~/GNUstep/Applications/Oolite, with a symlink in ~/.local/bin

Code: Select all

$ cd ~/.local/bin
$ ln -s ../../GNUstep/Applications/Oolite/Oolite_test_1.91.0.7728-251219-7857806-x86_64.AppImage oolite.appimage
$ cd /tmp
# User convenience: We can call it without path from anywhere as ~/.local/bin is in $PATH
$ oolite.appimage

# Select savefile. See that the OXP ship is replaced with a question mark.

$ grep load.failed  ~/.Oolite/Logs/Latest.log 
11:06:03.349 [load.failed]: ***** Failed to load saved game "Flibble-Z4-20251221-003.oolite-save": Could not find ship type “dtt_war_lance_player” - please reinstall the appropriate OXP.

So that's not working as expected. If it did, then dropping the appimage file in ~/GNUstep/Applications/Oolite and sym-linking from somewhere in $PATH would result in OX[PZ]s being found in ~/GNUstep/Applications/Oolite/AddOns.

I note that command line arguments are passed through to oolite. I've not dived into appimage or your methods, but would guess that the legacy wrapper scripts which launch the oolite binary still exist in some form. If APPIIMAGE cannot work, would it be particularly hard to add the one-liner I'd suggested suggested yesterday into those scripts. A positive test could warn about upcoming deprecation as well as changing $pwd to work around this issue. Maybe add a 'custom OXP paths' command line option.

OT: I found that running with a garbage argument (I mistyped --help as --helo) is simply ignored, so Oolite launches fully. Perhaps for unrecognised command line arguments Oolite should spit out the help text then exit.

In legacy, the script ~/GNUstep/Applications/Oolite/oolite checks for first run, shows a couple if file if so, touches a file to say they've been seen, and then runs ~/GNUstep/Applications/Oolite/oolite.app/oolite-wrapper which in turn contains the lines:-

Code: Select all

OOLITE_ROOT=$(cd $(dirname $0); cd ..; pwd -P)

# and later...

cd ${OOLITE_ROOT}/
./oolite.app/oolite "$@"
RC=$?

Perhaps these stanzas (if they exist in similar form in your appimage) might be the source of some confusion.

At the moment the appimage just runs the oolte executable directly. It could be changed to do something else internally like run a script that launches oolite.

To avoid confusion I'll mention here that an AppImage has its own internal filesystem which uses squashfs. You can see the folder structure by running the folloowing which will extract the appimage folder structure to a folder in the current directory:

Code: Select all

./oolite*.AppImage --appimage-extract

"When you double-click an AppImage, it mounts itself and looks for a file named AppRun in the root of the AppImage directory (root of internal filesystem).

If AppRun is a binary: The system executes it directly.

If AppRun is a shell script: The system executes the script.

If AppRun is a symlink: It executes whatever the symlink points to (which can be your wrapper script)."

I'm a bit confused about what you are trying to do or what we want here. I have some questions (these concern the distro's filesystem not the internal appimage filesystem):

1. With regard to finding addons, the AppImage could look in various places:
a. The folder in which the .AppImage file is located
b. The folder of the symlink that launches the AppImage
c. The working directory at time of launch (which could be different to both 1 and 2 above)

eg. 1a could be ~/Downloads/ where oolite*.AppImage resides. 1b could be ~/.local/bin where oolite.appimage symlink resides. 1c could be anywhere such as ~.

Perhaps the simplest is to check all 3 to cover all bases. What do you think?

2. Should there be a launcher script in the AppImage itself?
a. If so, should that script check for first run and show a couple of files?
b. Given the working directory will be 1c, should it cd to another folder and if so should it cd to 1a or 1b? Or is this taken care of if the AppImage looks in multiple places for the AddOns folder?
c. Is there anything else that the script should do before or after launching the oolite executable?

[MrFlibble]

At the moment the appimage just runs the oolte executable directly. It could be changed to do something else internally like run a script that launches oolite.

To avoid confusion I'll mention here that an AppImage has its own internal filesystem which uses squashfs. You can see the folder structure by running the folloowing which will extract the appimage folder structure to a folder in the current directory:

Code: Select all

./oolite*.AppImage --appimage-extract

"When you double-click an AppImage, it mounts itself and looks for a file named AppRun in the root of the AppImage directory (root of internal filesystem).

If AppRun is a binary: The system executes it directly.

If AppRun is a shell script: The system executes the script.

If AppRun is a symlink: It executes whatever the symlink points to (which can be your wrapper script)."

Good to know. Thanks. That might help me test and diagnose more rapidly.

I'm a bit confused about what you are trying to do or what we want here. I have some questions (these concern the distro's filesystem not the internal appimage filesystem):

1. With regard to finding addons, the AppImage could look in various places:
a. The folder in which the .AppImage file is located
b. The folder of the symlink that launches the AppImage
c. The working directory at time of launch (which could be different to both 1 and 2 above)

Perhaps the simplest is to check all 3. What do you think?

My instinct is that a and b are flawed, as I'm not likely to be putting AddOns under ~/.local/bin or ~/bin, or indeed anywhere else under my normal paths for executables.

c has some mileage. A symlink in the path can be called without directory prefix from any $PWD.

Still, I feel the user, transitioning from old installer, should not be bothered with any of this.

In order to be able to launch from a symlink under a current $PATH directory, whilst still finding OX[PZ]s installed in AddOns folder in what 'was' the starting directory for old style installer, either we have to use a wrapper script in e.g. ~/.local/bin which changes directory to ~GNUstep/Applications/Oolite before running the appimage (wherever it may be), or add ~GNUstep/Applications/Oolite to the search path of Oolite.

Such a wrapper script could indeed be AppRun. The behaviour could be masked with a system variable for those who wish to use $PWD and ignore old home. Something along the lines of:-

Code: Select all

# This will only cd to ~/GNUstep/Applications/Oolite if $OoliteNoOldOXP
# is empty AND ~/GNUstep/Applications/Oolite/AddOns is a directory.
# A further test could check if AddOns is empty and skip if so.

if [ "x$OoliteNoOldOXP" != "x" ] ; then
  if [ -d ~/GNUstep/Applications/Oolite/AddOns] ; then
    cd ~/GNUstep/Applications/Oolite && setbreak SeeBelow
    # Can't remember offhand how to set a trap to cd - on break or exit. Can look it up later.
  fi
fi
# Now run oolite binary, passing args to it.

2. Should there be a launcher script in the AppImage itself?
a. If so, should that script check for first run and show a couple of files?
b. Given the working directory will be 1c, should it cd to another folder and if so should it cd to 1a or 1b? Or is this taken care of if the AppImage looks in multiple places for the AddOns folder?
c. Is there anything else that the script should do before or after launching the oolite executable?

2: As above. I think so.
a: Checking for first run, and maybe adding an "appimage specific first run flag file" could be useful. If appimage first run, but not Oolite first run, we know the installer 'may' have been used.
b: As mentioned above, I feel 1a and 1b are not so useful. Having the appimage look in multiple 'standard' locations for AddOns is a good idea. Perhaps adding a way to specify a list of AddOns folders with command line args would be really useful to test different scenarios, and might even be useful for Hiran's Starter. In the short term, detecting ~/GNUstep/Applications/Oolite/AddOns, then cd to the directory above that should take care of this particular issue.
c: I'll think about that one...

[mcarans]

At the moment the appimage just runs the oolte executable directly. It could be changed to do something else internally like run a script that launches oolite.

To avoid confusion I'll mention here that an AppImage has its own internal filesystem which uses squashfs. You can see the folder structure by running the folloowing which will extract the appimage folder structure to a folder in the current directory:

Code: Select all

./oolite*.AppImage --appimage-extract

"When you double-click an AppImage, it mounts itself and looks for a file named AppRun in the root of the AppImage directory (root of internal filesystem).

If AppRun is a binary: The system executes it directly.

If AppRun is a shell script: The system executes the script.

If AppRun is a symlink: It executes whatever the symlink points to (which can be your wrapper script)."

Good to know. Thanks. That might help me test and diagnose more rapidly.

My instinct is that a and b are flawed, as I'm not likely to be putting AddOns under ~/.local/bin or ~/bin, or indeed anywhere else under my normal paths for executables.

c has some mileage. A symlink in the path can be called without directory prefix from any $PWD.

Still, I feel the user, transitioning from old installer, should not be bothered with any of this.

In order to be able to launch from a symlink under a current $PATH directory, whilst still finding OX[PZ]s installed in AddOns folder in what 'was' the starting directory for old style installer, either we have to use a wrapper script in e.g. ~/.local/bin which changes directory to ~GNUstep/Applications/Oolite before running the appimage (wherever it may be), or add ~GNUstep/Applications/Oolite to the search path of Oolite.

Such a wrapper script could indeed be AppRun. The behaviour could be masked with a system variable for those who wish to use $PWD and ignore old home. Something along the lines of:-

Code: Select all

# This will only cd to ~/GNUstep/Applications/Oolite if $OoliteNoOldOXP
# is empty AND ~/GNUstep/Applications/Oolite/AddOns is a directory.
# A further test could check if AddOns is empty and skip if so.

if [ "x$OoliteNoOldOXP" != "x" ] ; then
  if [ -d ~/GNUstep/Applications/Oolite/AddOns] ; then
    cd ~/GNUstep/Applications/Oolite && setbreak SeeBelow
    # Can't remember offhand how to set a trap to cd - on break or exit. Can look it up later.
  fi
fi
# Now run oolite binary, passing args to it.

2: As above. I think so.
a: Checking for first run, and maybe adding an "appimage specific first run flag file" could be useful. If appimage first run, but not Oolite first run, we know the installer 'may' have been used.
b: As mentioned above, I feel 1a and 1b are not so useful. Having the appimage look in multiple 'standard' locations for AddOns is a good idea. Perhaps adding a way to specify a list of AddOns folders with command line args would be really useful to test different scenarios, and might even be useful for Hiran's Starter. In the short term, detecting ~/GNUstep/Applications/Oolite/AddOns, then cd to the directory above that should take care of this particular issue.
c: I'll think about that one...

I think we should keep in mind that while we want to make things as easy as possible for existing users to keep existing folder layouts, with multiple build types like MSIX, NSIS, flatpak, appimage, source and with new players who may existing layouts confusing or inconvenient, we probably need to make standardised and cleaned up layouts, hence I've proposed in the suggestion thread that all the folders be configurable by environment variables (which would also be helpful to tools like OoliteStarter).

The appimage could take command line arguments that override the environment variable defaults and/or to choose a mode such as a compatibility mode to support existing usage.

Regarding making app menus for appimages, that is best done using Gear Lever. Gear Lever (perhaps a bit ironically) is available as a flatpak.

Speaking of flatpak, it would be a better option for new users since it integrates nicely with system package managers. It even allows piping in an external script eg. flatpak run --command=sh space.oolite.Oolite -c "$(cat myscript.sh)", but the restriction on folder access to ~/.var/app/space.oolite.Oolite/ would not allow a compatibility mode which requires access to other folders on the user's drive.

[MrFlibble]

I think we should keep in mind that while we want to make things as easy as possible for existing users to keep existing folder layouts, with multiple build types like MSIX, NSIS, flatpak, appimage, source and with new players who may existing layouts confusing or inconvenient, we probably need to make standardised and cleaned up layouts, hence I've proposed in the suggestion thread that all the folders be configurable by environment variables (which would also be helpful to tools like OoliteStarter).

The appimage could take command line arguments that override the environment variable defaults and/or to choose a mode such as a compatibility mode to support existing usage.

Sounds good to me. As long as we have managed and unmanaged paths for OX[PZ]s, and they can be changed at runtime, then all is peachy. I still think a search for OXPs in the GNUstep folders by Oolite startup (or scripts) would be a friendly default. If those locations are empty at launch, set e.g. "new layouts = true" in "flatpak launched" flag file, a flag which could be toggled by the user if ever they needed to bring in a legacy backup, or switch from old folders to new.

Regarding making app menus for appimages, that is best done using Gear Lever. Gear Lever (perhaps a bit ironically) is available as a flatpak.

Cool. I'll have a look at that.

Speaking of flatpak, it would be a better option for new users since it integrates nicely with system package managers.

It's certainly less work than maintaining packages for all platforms though those would arguably be more efficient on the target machines.

It even allows piping in an external script eg. flatpak run --command=sh space.oolite.Oolite -c "$(cat myscript.sh)",

Cool!

but the restriction on folder access to ~/.var/app/space.oolite.Oolite/ would not allow a compatibility mode which requires access to other folders on the user's drive.

Moving (or copying) OX[PZ] folders into directories within ~/.var/app/space.oolite.Oolite/ is trivial for most, as long as the requirement is made obvious to the user. Please pardon my ignorance, but what would invoke that restriction? It is not so with the current test flatpaks.

[mcarans]

I think we should keep in mind that while we want to make things as easy as possible for existing users to keep existing folder layouts, with multiple build types like MSIX, NSIS, flatpak, appimage, source and with new players who may existing layouts confusing or inconvenient, we probably need to make standardised and cleaned up layouts, hence I've proposed in the suggestion thread that all the folders be configurable by environment variables (which would also be helpful to tools like OoliteStarter).

The appimage could take command line arguments that override the environment variable defaults and/or to choose a mode such as a compatibility mode to support existing usage.

Sounds good to me. As long as we have managed and unmanaged paths for OX[PZ]s, and they can be changed at runtime, then all is peachy. I still think a search for OXPs in the GNUstep folders by Oolite startup (or scripts) would be a friendly default. If those locations are empty at launch, set e.g. "new layouts = true" in "flatpak launched" flag file, a flag which could be toggled by the user if ever they needed to bring in a legacy backup, or switch from old folders to new.

In this PR, I've made all folders configurable by environment variable:
https://github.com/OoliteProject/oolite/pull/536

On Linux, these environment variables are set in a script before running Oolite:
export OO_SAVEDIR="${OO_SAVEDIR:-${GAME_DATA}/SavedGames}"
export OO_SNAPSHOTSDIR="${OO_SNAPSHOTSDIR:-${GAME_DATA}/Snapshots}"
export OO_LOGSDIR="${OO_LOGSDIR:-${GAME_DATA}/.logs}"
export OO_MANAGEDADDONSDIR="${OO_MANAGEDADDONSDIR:-${GAME_DATA}/.ManagedAddOns}"
export OO_ADDONSEXTRACTDIR="${OO_ADDONSEXTRACTDIR:-${GAME_DATA}/AddOns}"
OO_GNUSTEPDIR="${OO_GNUSTEPDIR:-${GAME_DATA}/.GNUstep}"
OO_GNUSTEPDEFAULTSDIR="${OO_GNUSTEPDEFAULTSDIR:-${GAME_DATA}}"

All these can be overridden by the user setting these variables before running the AppImage. OO_ADDONSEXTRACTDIR is where managed addons will be extracted to.

OO_DIRTYPE is usually unset. In this case, the setup will be portable ie. use current folder/GameData/ for Oolite folders.
If the user sets OO_DIRTYPE to legacy, the old folders will be used (~/.Oolite ~/saved-games ~/GNUstep etc.)
If the user sets OO_DIRTYPE to xdg, ~/.local/share is used with new folder names like SavedGames, .ManagedAddons etc.

OO_ADDITIONALADDONSDIRS can be set by the user to pass a comma separated list of additional OXP folders.

These variables could also be used by Windows but are not currently.