Closed probonopd closed 4 years ago
Hi @probonopd I'm not familiar with AppImage, so I don't know the difference. The decision to use OPK packages for the GCW Zero was not taken by me, but by the OpenDingux developers. OPK files are archives with a Squashfs file system and a desktop file for metadata. They basically contain the directory of a game or program, such as executable, assets etc. See information for SquashFS and Desktop files
Thanks for the response @Harteex.
OPK files are archives with a Squashfs file system and a desktop file for metadata. They basically contain the directory of a game or program, such as executable, assets etc.
So are AppImages. Hence my question. Who might be able to answer it?
An OPK is just a dumb squashfs image, with data inside and one or more .desktop. Nothing else. It's expected to be mounted at a fixed mountpoint (so using absolute paths is possible), and the data inside is read-only. The OPK is mounted only when the app is started.
OPKs were introduced in 2012, at that moment either AppImage did not exist, or nobody knew it existed, so that's your answer.
Thanks @pcercuei. An AppImage is a squashfs image too, with data inside and one main .desktop. It's mounted at ever-changing paths to eoncourage people use relative paths, making apps relocatable, and the data inside is also read-only. The AppImage is also mounted only when the app is started.
Let me know if you would like to learn more about it, otherwise let's close here.
@probonopd The forced use of relative paths is what makes it unpractical for us. We don't want to butcher every library / app that is ported so that they work with relative paths. This is a Linux distribution, not OSX.
Also, I did try it "recently" (in the last two years or so) but couldn't manage packaging an app. The linuxdeploy tool only seems to create appimages valid for the host machine, while we need to cross-compile everything.
Thanks for the clarification @pcercuei. https://github.com/project-portable/libunionpreload can be used to work around the "absolute paths" issue, it can merge the content of the AppImage so that it appears to the application as if it was in /
. So, if you put something into usr/bin
inside the AppImage then the application thinks it is in /usr/bin
.
(About crosscompiling, this is something for which we simply haven't had a use case yet, but should be very easy to add to linuxdeploy if there is demand for it. Basically we would just need to use another pre-compiled runtime for another architecture.)
libunionpreload looks like a band-aid on top of a broken design... And even if we technically could use AppImages with dirty workarounds such as this one, what would be the compelling reason to do so? OPK has been working really well for us, and I don't see anything in AppImages that would warrant a switch.
Besides, OPKs have features that AppImages lack, for instance the possibility to have multi-arch packages (e.g. one single OPK that will run on ARM, MIPS, x86).
And no, pre-compiled runtimes don't work; you can't cover the combination of archs and C libraries. You'd have to cross-compile the loader software using the toolchain's compiler.
Hi @Harteex, someone over at https://www.reddit.com/r/RG350/comments/fgv6d7/the_difference_between_opk_and_appimage/ is asking about the differences of the
opk
format to AppImage. As the AppImage creator, I am wondering the same thing. Can you enlighten us? Specifically: Did you know about AppImage and if so, are there aspects that you thought were not fitting for your use case?