Appimagekit: [Feature request] Implement `--appimage-man`

[KurtPfeifle]

User story:

"As a user, I want to be able to access and read all man pages (and potentially other documentation) that an AppImage maintainer (or the developer of the respective app) has embedded into the image."

I'd expect the man page(s) to get printed in the terminal output, when I run
myApp.AppImage --appimage-man
from the command line. Should there be several relevant man pages, I'd expect to find out a standard way to select the one I need....

But maybe you guys can come up with an even more convenient method?

---

^{(This feature request may need thorough discussion and preparation work first. A standard way to implement this should possibly be specified in the AppImage spec draft document.)}

[probonopd]

What goes into an AppImage and what command line options the things inside the AppImage support or don't support are outside of the scope for AppImageKit, so I would prefer to leave this up to the person putting together an AppImage. All of this can easily be achieved by using a custom AppRun script.

Especially, we don't want to force people to write a man page, as this is cumbersome and usually not available for most GUI applications.

[TheAssassin]

All of this can easily be achieved by using a custom AppRun script.

Just for completion, beware that --appimage* options are reserved for the AppImage runtime, i.e., you need to choose another prefix.

[KurtPfeifle]

@probonopd argued:

"What goes into an AppImage and what command line options the things inside the AppImage support or don't support are outside of the scope for AppImageKit [....]"

I disagree. I disagree in so far that the AppImage format should not put up an extra obstacle to access stuff (functionality and documentation) which is inside the AppImage, and which users may want to see.

It is the task of the AppImage runtime and the standard AppRun to help users discover that stuff and give them an option to also see it. What "goes into an AppImage and what command line options the things inside the AppImage support or don't support are" EXACTLY the scope for AppImageKit!

Of course, you could say: "We artificially LIMIIT our scope to just run one single application from inside the AppImage, and it is the job of the packager to define which one it is."

"[....] so I would prefer to leave this up to the person putting together an AppImage."

Of course, IN THE END it is up to the packager, what he wants to include and what not.

But why not make it EASY for him to also include documentation snippets?
And why not automate this as far as possible by supporting it thru the standard AppRun?

"All of this can easily be achieved by using a custom AppRun script."

Why use a custom AppRun script if the standard one could also support it? The only thing which would need to be done (I'm not saying yet, that this "only" thing is EASY!) is that the AppImage project would need to lay down specs for this in the format spec document and the packagers to follow this in their packaging practise.

[KurtPfeifle]

@TheAssassin wrote:

"Just for completion, beware that --appimage options are reserved for the AppImage runtime, i.e., you need to choose another prefix."*

Maybe I didn't express my wish clear enough? Sorry then...

No, I want exactly such a prefix to be used, because I want the AppImage default AppRun and runtime to support it and hence use such a prefix!

And I want the collective brain power of AppImage developers to come up with an simple, lightweight solution to achieve this, so AppImage packagers could also easily get it automatically added into the packages they build.

(I don't say this is the NEXT feature to be supported, or that it must be within the next 12 months. I have no idea what you guys have on your roadmap next and how busy these goals will keep you....)

[TheAssassin]

No, @KurtPfeifle, what I was referring to is, you suggested to implement something in the runtime, whereas @probonopd suggested you to implement it in AppRun.

So, disregarding either opinion on the topic, I thought, before you (or, more importantly, anyone else who'd dig out this issue in the future) wondered why some argument prefixed with --appimage-* wouldn't ever ever reach the AppRun binary, I wanted to state that recently we decided to filter any such option out in the runtime, whether it is used or not. I don't really understand the :-1: in the other issue where I clarified this as well. Just a neutral note.

[KurtPfeifle]

"No, @KurtPfeifle, what I was referring to is, you suggested to implement something in the runtime, whereas @probonopd suggested you to implement it in AppRun."

Ok, I apologize for being clueless what should be in the runtime and what should be in the AppRun.

Whatever it is: my argument was for a standard way to to provide such a functionality. For an easy way of AppImage packagers to implement it (without a custom AppRun script) -- through the default AppRun or runtime (whichever) provided by the AppImage toolchain....

[probonopd]

There is no such thing as a "default" AppRun - for example, with linuxdeployqt we use a symlink.

[TheAssassin]

Exactly. This would have to be implemented in the runtime which is included in any AppImage built by the standard tools. Any additional feature will increase the size. And since the feature you request probably needs quite some auto detection logic. I think this is one of the primary reasons @probonopd reluctant to implementing such a feature.

[KurtPfeifle]

So you want to make me conclude that AppImage packaging hence never, ever will provide the full contents of "traditional" application packaging methods?! That it is reduced to achieve 99% at the most?

C'mon guys. I thought you had solved more complicated tasks already?

[probonopd]

@KurtPfeifle basically we think that AppImage is the un-package that does not come with many strict rules. Like a zip file with executables in it, but better, since you don't have to extract it, it can update itself, etc.

I can totally see the value of a strictly enforced packaging policy, mainly in combination with maintainers that know and follow it, but I don't think that a) we could do better than Debian in this regard, and b) I think this is the opposite of the AppImage "all power to upstream" approach.

If you look at macOS you will see that .app bundles in .dmg disk images are only used for GUI applications. We want to master in that category first.

Your questions arise from the fact that you are thinking about command line tools. Maybe it would be useful to have a __boilerplate AppRun file for command line tools__ as a separate project from this one that people making AppImages of command line tools could use. But please understand that the AppRun file is in the domain of the application contained inside the AppImage, it's not a feature of the AppImage format itself. In fact, we are working to make a simply symlink suffice as the AppRun entrypoint, with the option to use custom binaries and scripts in its place.

We really need to manage complexity, as there are currently no more than 2-3 permanent contributors here.