GNOME Bugzilla – Bug 794578
Properly handle ELF files
Last modified: 2018-03-24 17:14:02 UTC
It shouldn't be necessary for the end-user to modify the permission of an AppImage file to execute it. It's not an intuitive use case. AppImage being an ELF file. Quoting: " Desktop environments should ask the user whether to set the executable bit and then run the application when the user double-clicks on an ELF file that doesn't have the executable bit set. ... It should ask "do you want to mark this application as executable and launch it?". " More information: https://github.com/AppImage/AppImageKit/issues/374
From my point of view, this is essentially requesting support to install an application bundled as an AppImage. In the case of AppImages, installation as minimal as it gets, but it is still a form of installation, because you need to ask user consent to: 1) give execute permissions and (optionally), add, optionally: 2) install a .desktop launcher to see the app in the system's application list In my opinion, application installation belongs in the realm of gnome-software, not just conceptually, but also because it would provide a much nicer user experience than the file manager can. In gnome-software, the user could be provided more information (such as screenshots, application description, publisher, software licence, version, etc.) before deciding if they want to give it the execute permission it needs. Should this be reassigned to gnome-software?
To clarify, the user experience I'm thinking about would be something like this: 1) I download an AppImage file from a website. 2) I open that file, which pops up a gnome-software window, displaying details on the application (possibly also information about security), with a highlighted "Trust and Run" button. 3) I click "Trust and Run" and the application opens. (The executable bit is implicitly set.) The details would need more thought, but this is just an example.
@António please note that this issue is about the handling of _all_ ELF files, not just AppImages. AppImages are just an example use case, but there's lots of other use cases. I recommend reading the upstream issue on GitHub. As for desktop integration like you suggested, I recently started a proposal how AppImage desktop integration (a.k.a. "native AppImage support") could work when implemented on the system side. Please check out https://github.com/TheAssassin/AppImageLauncher. As for GNOME Software, there have been plans for working on a plugin to get AppImage support, see https://github.com/AppImage/AppImageKit/issues/58 and https://github.com/AppImage/AppImageKit/issues/244. There is no such product available by now. If the GNOME project was be working on this issue, it'd probably be finished way faster. For AppImage, this is not a priority issue. However, all this is off topic. This issue is about ELF files.
(In reply to TheAssassin from comment #4) > @António please note that this issue is about the handling of _all_ ELF > files, not just AppImages. AppImages are just an example use case, but > there's lots of other use cases. We usually triage bugs based on the needs of specific use cases. There are a user expectations and design assumptions that apply to AppImages, which do not necessarily hold for other use cases. Therefore, the adequate solution may differ, even if they share a common implementation detail (that being ELF). > I recommend reading the upstream issue on GitHub. The upstream issue is from the AppImage repository, and it is motivated from the needs of AppImage use case, as is quote: > > "Currently our users have to set the executable bit before they can run an AppImage. This apparently is a real barrier for them." My previous suggestion is a possible approach to the specific use case described. > As for desktop integration like you suggested, I recently started a proposal > how AppImage desktop integration (a.k.a. "native AppImage support") could > work when implemented on the system side. Please check out > https://github.com/TheAssassin/AppImageLauncher. That looks like an interesting tool for CLI to serve as a more powerful alternative to the a possible GUI solution like the one I've described. > As for GNOME Software, there have been plans for working on a plugin to get > AppImage support, see https://github.com/AppImage/AppImageKit/issues/58 and > https://github.com/AppImage/AppImageKit/issues/244. There is no such product > available by now. If the GNOME project was be working on this issue, it'd > probably be finished way faster. For AppImage, this is not a priority issue. Reassigning this issue to gnome-software could bring more attention to that need. > However, all this is off topic. This issue is about ELF files. We already have bug 604639 for that. I think it would be a waste to close it as a duplicate of a bug which shows show no signs of progress, when we have a reasonably well defined use case at hand which we could optimize for.
I see, 604639 seems like it's discussing what is suggested on GitHub. Please note that AppImageLauncher is _not_ a CLI tool, it's a UI implementing pretty much what you suggested. It lacks some docs currently, I'll be working on those next week. In the meanwhile, some background information can be found on https://github.com/TheAssassin/AppImageLauncher/wiki/Idea. You can find a .deb package on GitHub for testing it.
(In reply to TheAssassin from comment #6) > I see, 604639 seems like it's discussing what is suggested on GitHub. Ok, I'll mark as a duplicate then. Thanks for all the useful links! *** This bug has been marked as a duplicate of bug 604639 ***
Thanks. We will open a new bug regarding desktop integration of AppImages once we have a solution for this ready, too.