AppImageKit
AppImageKit copied to clipboard
AppImage
Document --appimage-extract-and-run
This is the most useful feature of AppImage for me. Should we document it? Seems relatively undocumented compared to others such as --appimage-extract
FUSE filesystems don't work so well on some distros so it can mess with the whole portability aspect of this which this is trying to solve I guess?
I'd also like to be able to surpress the extract output unless there is an error with extraction, is that possible? I use tmux appimage package for example and everytime you get this output which I don't need to know about:
/tmp/appimage_extracted_d5fc75edbd3f625b68b1c5c8a1bec900/usr/lib /tmp/appimage_extracted_d5fc75edbd3f625b68b1c5c8a1bec900/usr/lib/libevent-2.0.so /tmp/appimage_extracted_d5fc75edbd3f625b68b1c5c8a1bec900/usr/share/icons/hicolor/128x128 /tmp/appimage_extracted_d5fc75edbd3f625b68b1c5c8a1bec900/usr/share/icons/hicolor/256x256/apps /tmp/appimage_extracted_d5fc75edbd3f625b68b1c5c8a1bec900/usr/share/icons/hicolor/32x32
It's not documented very well because it's inefficient, I would say. But feel free to send a PR for https://github.com/AppImage/docs.appimage.org/ to add a section on it; this is long overdue.
FUSE filesystems don't works so well on some distros so it can mess with the whole portability aspect of this which this is trying to solve I guess?
What distros in particular?
I'd also like to be able to surpress the extract output unless there is an error with extraction, is that possible?
Duplicate of #1002. Your AppImage uses a really old runtime, I guess.
It was some RHEL6 I think I'll let you know. Maybe FUSE isn't configured on it. For tmux FUSE mounting seems like overkill anyway. For a portable tmux binary all you really need is a statically linked binary, a separate filesystem should not be needed. AppImage just provided a neat alternative to static linking I guess!
Well, with AppImage, you can bundle a lot of additional data, e.g., for desktop integration. That doesn't work with static binaries.
I think this issue needs to be split into two:
- we should list the option in the runtime's help
- we should document it in the docs
Any help would be appreciated.
We should also mention that if you need to use --appimage-extract-and-run, then your system is not properly configured and you should try resolving the underlying issue.
That kind of ruins the portability aspect if you depend on a certain configuration. There are users that find this useful, otherwise the feature wouldn't exist I guess? This system works fine for every other purpose?
If my AppImage program runs perfectly with --appimage-extract-and-run and for every other purpose, it's not misconfigured for my uses at least.
What @probonopd means is what I already explained: running with this flag is inefficient, and it's preferable to e.g., install or configure FUSE.
We do not want AppImages to degrade to "self-extracting archives". Also, the extracted files are not cached unless you export a special environment variable.
Fair enough, I'm eager to learn about the caching thing you mention. That seems useful, the extract on every execution behavior seems wasteful alright.
Although I did work around that by putting the relevant extracted bin and lib in /usr/bin and /usr/lib. Which understandably is not exactly how it's supposed to work. Meant to be more of a execute one file for everything approach I guess.
It's NO_CLEANUP: https://github.com/AppImage/AppImageKit/blob/master/src/runtime.c#L748-L754
The feature is designed so that the cache directory name is predictable (i.e., future executions will use the same cache dir, and the runtime will recognize that the dir exists).