Make runtime repo and tag configurable

[black-sliver]

I am aware of the maintainer situation and been considering switching to or merging in commits from Lord-Kamina/appimage-builder for "my own" fork, so @Lord-Kamina here.

One of the changes in that fork is allowing a custom AppRun, but what is missing is being able to specify a custom runtime. I would like to switch to my own that does tagged, immutable re-releases of the upstream continuous builds.

I think I've seen a custom runtime version (release tag) in a recipe somewhere, but I might be misremembering. I don't see support for that in the current sources. So, bonus question: is there a schema for recipes, if so, where is that hosted?

My suggestion would be adding tag or version and repo to the AppImage section in recipes and have them default to "continuous" and "appimage/type2-runtime" respectively to retain back compat.
I am wondering if we should maybe also switch the custom AppRun thing to be part of the recipe?

[Lord-Kamina]

With my fork, the way you do this (currently) would be by simply comitting the changes to your own fork of AppRun. I've set it up with an environment variable that allows you to select a custom fork.

There is also a variabe for the AppRun version but it's not quite free text, IIRC.

[black-sliver]

Maybe my wording is confusing. AppRun is not runtime.

runtime is the thing that mounts the squashfs, AppRun is the entrypoint inside the squashfs.

We can swap out AppRun in your fork, but not runtime.

[Lord-Kamina]

It should work all the same via the APPIMAGE_BUILDER_REMOTE_REPO_OWNER environment variable

when running from a local computer or shell. The CI action sets it automatically to the owner for where the job is running.

[Lord-Kamina]

You can't currently create multiple runtimes per-se but if you make changes to the runtime in your fork, they should get pulled.

What you can't do is have several different runtimes to pick and choose from. And I'm not quite sure why would you want to?

[black-sliver]

I think there is still some misunderstanding. I am talking about this line: https://github.com/Lord-Kamina/appimage-builder/blob/main/appimagebuilder/modules/prime/appimage_primer.py#L103

[Lord-Kamina]

I think there is still some misunderstanding. I am talking about this line: Lord-Kamina/appimage-builder@main/appimagebuilder/modules/prime/appimage_primer.py#L103

Ahh ok, I see, yes.

One way to deal with all these things might eventually be via changes to the recipe specification, but in the short-term you could probably also get it done using the same approach I took for the other changes I made.

Sometimes, "perfect" is an enemy to "good enough"... especially when talking about projects in dire need of attention such as this one. 🫠

[black-sliver]

I decided to go a different route for now:
I separately download appimage-builder, appimagetool, AppRun, libapprun_hooks and type2 runtime in CI now and check hashes, let appimage-builder just create the AppDir and use appimagetool to generate the actual AppImage. That way we don't get any unknown versions of anything.

I would very much prefer to integrate all of that into appimage-builder (once it's maintained again) because this workflow is somewhat annoying and error prone to do locally (outside of CI).

It looks something like this: black-sliver/PopTracker@4d483d3...ef17dcd