search

Harteex / OpenPackageCreator

Tool to easily build opk packages for OpenDingux
MIT License
27 stars 4 forks source link

Differences to AppImage? #1

Closed probonopd closed 4 years ago

probonopd commented 4 years ago

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?

Harteex commented 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

probonopd commented 4 years ago

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?

pcercuei commented 4 years ago

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.

probonopd commented 4 years ago

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.

pcercuei commented 4 years ago

@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.

probonopd commented 4 years ago

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.)

pcercuei commented 4 years ago

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.