Why use AppRun?

[overheadhunter]

Hi again!

I try to understand how best to organize the contents in my AppDir (which imo should get its own wiki page describing its structure).

One of the questions that arise is, what is the benefit of the AppRun binary over just using a shell script or even a symlink to the application binary?

In this thread Simon says this is perfectly possible:

Can I add a top-level directory for data dependencies?

AppRun.c sets it up this way, doing a chdir(usr/). Correct. But you don’t have to use this AppRun, you could also use your own script or even a link to your binary in its place. A safer method would be to find out the absolute path to your main executable, and calculate an absolute path to your data based on that, e.g., using the information from /proc/self/exe.

However the AppImage would then miss the --appimage-xyz options, that a user might know from different AppImages and expect to be present:

Call alternative binary from appimage?

Well, the architectural question is what should be handled by AppRun (YOUR launcher that is supposed to also work outside of an AppImage, e.g., in a standalone AppDir) vs. AppImage’s runtime.c (common to all AppImages)… which already has some --appimage-... options.

My thoughts:

• Are there any other benefits of using the provided AppRun binary?

• Will there be further options in the future? Like the integration of the update mechanism directly into the AppImage?

• Shouldn’t it be declared a best practice to always bundle the provided AppRun to guarantee a consistent behaviour across all AppImages?

Thanks and keep up the great work!

[probono]

@overheadhunter

AppDir (which imo should get its own wiki page describing its structure)

Thanks for the hint; added that page.

@overheadhunter

One of the questions that arise is, what is the benefit of the AppRun binary over just using a shell script or even a symlink to the application binary?

You can use a shell script or a symlink to the main executable, or the AppRun provided by AppImageKit. It really doesn’t matter as long as your AppRun file or symlink is capable of launching the main payload application correctly.

@overheadhunter

Are there any other benefits of using the provided AppRun binary?

Using the AppRun provided by AppImageKit takes care of launching the payload application for you in many cases, so it can save you from doing manual boilerplate code.

@overheadhunter

Will there be further options in the future? Like the integration of the update mechanism directly into the AppImage?

The AppRun file has nothing to do with the update mechanism. From our side we consider the AppRun provided by AppImageKit to be feature complete; if people have additional requirements they are welcome to write their own AppRun file (or extend the one in AppImageKit).

@overheadhunter

Shouldn’t it be declared a best practice to always bundle the provided AppRun to guarantee a consistent behaviour across all AppImages?

Not needed, since the only requirement of an AppRun file or symlink is to launch the main payload application. Every additional feature is a “specialty” of the respective AppImage and not something that all AppImages will (or should) support.

Code that should be common to all AppImages does not go into AppRun, but into runtime.c.

@overheadhunter

However the AppImage would then miss the --appimage-xyz options

These are not handled by AppRun but by runtime.c.

Remember that AppRun is an AppDir thing (predating AppImage and useable outside of AppImages) while runtime.c is an additional thing introduced by AppImage.

[overheadhunter]

@probono

These are not handled by AppRun but by runtime.c.

Remember that AppRun is an AppDir thing (predating AppImage and useable outside of AppImages) while runtime.c is an additional thing introduced by AppImage.

This was my main misconception! I thought, AppRun was somehow important for the AppImage “header”, but of course it is part of the iso payload!

Thanks for clarifying!