Wow, this is amazing! I'll check this out and review ASAP.

This is interesting.

I installed the lastest linuxdeploy AppImafe file to /usr/local/bin/linuxdeploy. Hoever, even after I explicitly do export LINUX_DEPLOY=/usr/local/bin/linuxdeploy, building the AppImage fails with

LINUX_DEPLOY variable must be set to the path of linuxdeploy binary
make: *** [ports.mk:632: appimage] Error 1

Any idea what I'm doing wrong here?

you will laugh...
I changed LINUX_DEPLOY to LINUXDEPLOY and forgot to change the error message...

BTW, as this PR also changes the appdata XML and desktop file, could you check that snap and flatpak packages are not broken?

BTW, as this PR also changes the appdata XML and desktop file, could you check that snap and flatpak packages are not broken?

The snap package is not affected, because I ship a modified scummvm.desktop file with it, so this is not touched by this change. Summoning @AsciiWolf for FlatPak 😁

Currently looking into the AppImage building itself.

I already found one thing that we might want to check against: AppImage requires libfuse2 to run, but current Linux distros ship with libfuse3, so we have to install this as an additional dependency. Unfortunately, this affects both building and running the AppImage.

When calling linuxdeploy, we also have to explicitly specify the names of the executable, the desktop file and an icon file. For this test, I took the 512x512 PNG file from the scummvm-media repo and placed it in the scummvm source root:

diff --git a/ports.mk b/ports.mk
index 51126b2f99f..00c9a1503b7 100644
--- a/ports.mk
+++ b/ports.mk
@@ -632,7 +632,7 @@ appimage:
        @if [ -z "$(LINUXDEPLOY)" ]; then echo "LINUXDEPLOY variable must be set to the path of linuxdeploy binary" >&2; exit 1; fi
        rm -rf "$(APPDIR)"
        $(MAKE) install DESTDIR="$(APPDIR)"
-       VERSION="$(VERSION)$(VER_REV)" "$(LINUXDEPLOY)" --appdir="$(APPDIR)" -o appimage
+       VERSION="$(VERSION)$(VER_REV)" "$(LINUXDEPLOY)" --appdir="$(APPDIR)" --desktop-file="$(APPDIR)/usr/local/share/applications/org.scummvm.scummvm.desktop" -i scummvm.png -e scummvm -o appimage
 
 #
 # Special target to generate project files for various IDEs

[appimage/stderr] WARNING: AppStream upstream metadata is missing, please consider creating it
[appimage/stderr]          in usr/share/metainfo/org.scummvm.scummvm.appdata.xml
[appimage/stderr]          Please see https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
[appimage/stderr]          for more information or use the generator at http://output.jsbin.com/qoqukof.

I remember I had to do this for the Raspberry Pi image itself, so this doesn't seem to be an issue with how the desktop file is named.

With this change, I was able to successfully build the AppImage. We might want to consider disabling the local fileserver though, because this will most likely break due to the AppImage confinement. However, I think this is an issue for a seperate task after AppImage support is working in general.

If you want to give it a try, I have a test build built with Ubuntu 23.04 here: https://storage.scummvm.org/s/X7YzdbJFjsRAdcp

Oh, and btw, if you want to have some referencence manual: The folder https://storage.scummvm.org/s/sckHC2iBdktEdkM contains the wrapper and build scripts I used for the current Raspberry Pi image. This is by no means a "pretty" build script, but it does the job.

Adding "zenity" for a minimalistic GUI is no problem there since I only target Raspberry Pi OS, so I don't have to care about this dependency. This might be a bit more difficult if we want to do this in the "general purpose" makefile target.

Consider renaming the AppStream metadata file to org.scummvm.scummvm.metainfo.xml. The metainfo.xml suffix is a preferred one if you install the file into the metainfo directory.

This is now done.
I have limited time so I preferred to tackle all metainfo updates first and will look at AppImage problems in a second time.

The changes look good, thanks!
(Although I don't have any experience with the <icon type="stock"> tag.)

(Although I don't have any experience with the <icon type="stock"> tag.)

I don't have either but with local type you need a full path... :|

Is the icon tag needed? I have never used it and when reading the specification or how it is used in the example file, it looks like some fallback generic icon name. I would probably remove it, the correct icon name is already in the desktop file.

Yes, you are right. Better removing it.
I did it.

I already found one thing that we might want to check against: AppImage requires libfuse2 to run, but current Linux distros ship with libfuse3, so we have to install this as an additional dependency. Unfortunately, this affects both building and running the AppImage.

Indeed, it's a limitation of current AppImage (per AppImage/AppImageKit#1120).
We could switch to probonopd/go-appimage which links statically and should be immune to this problem but it's not considered as stable.

In fact, the generated AppImage also misses some libraries (like freetype, libstdc++, ...). Official AppImage build instructions recommend to use the latest LTS still supported distribution like CentOS 7 (which is unmaintained now).
This is not something really handy. I will do some tests with go-appimage to see how it goes.

When calling linuxdeploy, we also have to explicitly specify the names of the executable, the desktop file and an icon file.

I was really puzzled by what you said because it worked perfectly for me without adding any option and I realized that I run configure with --prefix=/usr. This is what is expected to build AppImages: application is supposed to reside in AppDir/usr and not AppDir/usr/local.
Should I add a check that prefix is correct when building?

With this change, I was able to successfully build the AppImage. We might want to consider disabling the local fileserver though, because this will most likely break due to the AppImage confinement. However, I think this is an issue for a seperate task after AppImage support is working in general.

The AppImage isn't concealed itself, it's just some directory mounted and a binary run from there.
An additional home can be stored besides it but nothing prevents you to browse the whole filesystem.

Currently AppImage is a make target so we can't really disable things when running it.

Oh, and btw, if you want to have some referencence manual: The folder https://storage.scummvm.org/s/sckHC2iBdktEdkM contains the wrapper and build scripts I used for the current Raspberry Pi image.

Thanks, but your wrapper seems to install the binary on the filesystem (like an installer). I don't think it's the purpose of AppImage which are supposed to be run directly.

In fact, the generated AppImage also misses some libraries (like freetype, libstdc++, ...). Official AppImage build instructions recommend to use the latest LTS still supported distribution like CentOS 7 (which is unmaintained now). This is not something really handy. I will do some tests with go-appimage to see how it goes.

Uh, that's interesting, I'll have a look at it and see how well it works.

When calling linuxdeploy, we also have to explicitly specify the names of the executable, the desktop file and an icon file.

I was really puzzled by what you said because it worked perfectly for me without adding any option and I realized that I run configure with --prefix=/usr. This is what is expected to build AppImages: application is supposed to reside in AppDir/usr and not AppDir/usr/local. Should I add a check that prefix is correct when building?

Yes, that's a good idea - I didn't modify the prefix at all, so that's likely what caused the issue (I wasn't aware that /usr is expected in AppImages).

Oh, and btw, if you want to have some referencence manual: The folder https://storage.scummvm.org/s/sckHC2iBdktEdkM contains the wrapper and build scripts I used for the current Raspberry Pi image.

Thanks, but your wrapper seems to install the binary on the filesystem (like an installer). I don't think it's the purpose of AppImage which are supposed to be run directly.

Yes, the wrapper provides an additional option to either run it "on the fly" (as usually expected) or "embed" the AppImage to the system - some users prefer this way, so I provided a solution for both.

In fact, the generated AppImage also misses some libraries (like freetype, libstdc++, ...). Official AppImage build instructions recommend to use the latest LTS still supported distribution like CentOS 7 (which is unmaintained now). This is not something really handy. I will do some tests with go-appimage to see how it goes.

Uh, that's interesting, I'll have a look at it and see how well it works.

I've added support to go-appimage. This is not completely failsafe (it fails to parse the include directive in /etc/ld.so.conf and fails to find the icon in scalable subdirectory) but it works and produces a full bundle which doesn't depend on anything on the target system (except some standard utilities like find, grep and so on)

When calling linuxdeploy, we also have to explicitly specify the names of the executable, the desktop file and an icon file.

I was really puzzled by what you said because it worked perfectly for me without adding any option and I realized that I run configure with --prefix=/usr. This is what is expected to build AppImages: application is supposed to reside in AppDir/usr and not AppDir/usr/local. Should I add a check that prefix is correct when building?

Yes, that's a good idea - I didn't modify the prefix at all, so that's likely what caused the issue (I wasn't aware that /usr is expected in AppImages).

Done.

Oh, and btw, if you want to have some referencence manual: The folder https://storage.scummvm.org/s/sckHC2iBdktEdkM contains the wrapper and build scripts I used for the current Raspberry Pi image.

Thanks, but your wrapper seems to install the binary on the filesystem (like an installer). I don't think it's the purpose of AppImage which are supposed to be run directly.

Yes, the wrapper provides an additional option to either run it "on the fly" (as usually expected) or "embed" the AppImage to the system - some users prefer this way, so I provided a solution for both.

It seems that there is now a appimaged binary which monitors appimages and "registers" them to the system.

I've added support to go-appimage. This is not completely failsafe (it fails to parse the include directive in /etc/ld.so.conf and fails to find the icon in scalable subdirectory) but it works and produces a full bundle which doesn't depend on anything on the target system (except some standard utilities like find, grep and so on)

This is now fixed in latest tag

OK... Let's merge this!

Thank you, everyone!