AppImage
AppImage --install #1255
Replies: 9 comments 10 replies
-
|
First of all: wrong term. We call it integration, not installation, for a reason. Second, there used to be built-in integration. It turned out to be a really poor idea, hence it was removed and replaced with external tools. Discussed so many times here and in other places like the old forum. There is no point in reiterating the same questions all over and over again. Please use the search. |
Beta Was this translation helpful? Give feedback.
-
|
Jeez. Sorry I asked. |
Beta Was this translation helpful? Give feedback.
-
|
I see -- you are the author of AppImageLauncher, hence your reply.
I'm relatively new to AppImage, so there's no particular reason why I would know about the old "the old forum".
This is like people coming to a forum to ask a question and being told to "use Google" instead. Hence, the forum becomes pointless.
Why was it a really poor idea? |
Beta Was this translation helpful? Give feedback.
-
That's got nothing to do with my response. I was involved in terminating the use of built-in integration long before I started working on AppImageLauncher. However, you can't imagine how exhausting it can be to answer the same question over and over again for years. For instance, we have docs. These docs were a lot of work to put together, most texts being written by me. Yet, maintainers (and community members) keep maintaining redundant and hence unnecessary wiki pages that tend to get outdated, filled with unrelated, off topic contexts or vandalized. I've integrated new knowledge into the docs and placed a link in the wiki in place of the old page. This keeps getting undone. I mean, there's a link to the same information that is in a way better shape than that Wiki page. In what way does this offend people? Contributing in a reviewed process seems to be asked too much. My language has become harsher in the last years in the AppImage community. I don't mean it personal in any way. Please don't feel offended. I'm criticising the idea. This kind of super annoying behavior by @probonopd and our community also keeps killing my motivation investing time into AppImage. There are other projects out there that can benefit from my work as well and are less annoying to work with. That said, I still keep things going in this project continuously... But yeah, look at why AppImageLauncher hasn't seen much activity in three (!) years.
https://discourse.appimage.org/
Not really. Most old issues just have not been converted to discussions as of yet. That doesn't mean there are no answers in the issues. In fact, there are. I replied many times to exactly such questions. You can just use the search as easy as me. There is however no point in me doing it for you and posting links here. That kind of work just prevents people like me spending time on bugs and features. It seems pretty clear to me that you have not searched the closed issues. You implied this yourself.
Ah, here we go again, me replying to the same question. I'll keep it short. You'll find more details in the old issues. Aging code in old AppImages meaning incompatibilities with newer systems, inconsistencies in the included bash script, poor UI/UX due to the use of zenity and alike (which were not bundled!), no specification on how integration algorithms should work with each other, et cetera et cetera. Also, bloat. The advantage of having a proper tool outside of AppImages is simple: you can actually fix problems and incompatibilities on newer distributions. Plus, you can implement way more advanced strategies like AppImageLauncher does compared to just copying one desktop file and one icon around. Please note that the old integration did not "install", it did not use sudo etc. A popup asked whether to copy a desktop file and icon to If your idea uses |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the detailed reply and the links.
Rather I was feeling positive about AppImage and had an idea which I suggested and described. I noted that it had probably been thought of and didn't come with the notion of pushing it forward no matter what. Rather, I simply wrote a post with a suggestion and wondered what response I would get. Naive perhaps, but I didn't think my behaviour to be so wrong. But more to the point...
Yes, I can certainly see this. But then, isn't it the case that RPM and deb packages merely have their contents unpacked into fixed directories? Do they not suffer the same lack of future-proofing? In any case, I see that you have clearly thought about it all a great deal, and I don't wish to burden you. Like I say, I'm not hell bent on seeing through "my idea" and clearly accept that it is non-starter. I am grateful that you have gone to the trouble to explain it. All the best Andy |
Beta Was this translation helpful? Give feedback.
-
|
Hi @kuiperzone, really appreciate your thoughts. Thing is, I think how Gnome (and the XDG specs) handles applications is pretty unflexible, since it assumes that things are in static locations. The AppImage format was specifically made so that you can move applications around freely in the filesystem. So, by adopting the Gnome/XDG ways of doing things would essentially "downgrade" the AppImage user experience to the Gnome/XDG user experience. We are not looking at Gnome/XDG for inspriation, but at systems like RISC OS, NeXTSTEP, and GNUstep. We are aiming for a workflow in which you don't need package managers, GNOME Software, and similar tools, and where everything can be done by drag-and-drop in the file manager. At this point, Linux users seem to be so conditioned on "installing" and "managing" "packages" that when you have a system that needs no "installing", no "managing" (other than what you can do by drag-and-drop in the file manager), and no "packages" (hence no dependencies other than the base OS), then people want to bolt the packages/installing/... workflows on top of them. To me personally, this feels backward.
Only if newer systems are paying no attention to staying backward compatible (which, oddly, Windows is doing a rather good job at). What we need is a stable interface that applications can rely on forever. This is missing in the uncoordinated "Linux" userland stack, because apparently the distribution makers (and Linux Foundation) seem to have no interest in this. So the only stable interface that can be relied in seems to be the kernel-to-userland interface. Hence, I am increasingly leaning toward developing against that interface only, which means to bundle everything an application needs to run privately in each AppImage. Since the kernel-to-userland interface is known not to break, this should (at least directionally) lead to forever-working AppImages. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @probonopd , I like your thinking on this. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
Hi @TheAssassin
Can you explain this? I feel it would really be helpful. I ask because I have spent an inordinate amount of time pouring over the RPM spec file format, and it has driven me mental. I realised however that the problem I was having was one of terminology. They appear to refer to building (i.e. making or compiling) the app as "BUILD". And refer to what I would call "building the package" as "INSTALL". I was left deeply perplexed as what do you call the process of installing the package on the target system -- "INTEGRATION"? |
Beta Was this translation helpful? Give feedback.
-
|
"Installing" traditional "Linux" packages means copying files into places like With AppImage, the "installer" and the "installed" version are one and the same - because in fact AppImages require no unpacking to the filesystem, and no installation in the traditional sense. The software stays inside the file that was used for downloading the software at all times. "Integration" just means making the file manager, menu etc. of the operating system aware of the additional application. This does not involve copying files to |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure it's useful to make this distinction between "installation" and "integration". Apple describes the whole "Drag to When new user discovers AppImage, you want them to understand:
This is complicated enough without introducing a whole new term that you then have to explain on top of everything else. |
Beta Was this translation helpful? Give feedback.
-
|
To be clear, you can still use the term "integration", but I would do so like this: "AppImages can optionally be installed to integrate them properly with your desktop environment. For example, this would make the program appear in your system's application launcher along with all your other apps." This is perfectly accurate and saves you from having to go through the whole "it's called integration, not installation!" spiel, which isn't exactly the friendliest of welcoming new users. |
Beta Was this translation helpful? Give feedback.
-
|
Thank guys, you've both been incredibly helpful. |
Beta Was this translation helpful? Give feedback.
-
|
@kuiperzone, we actually do this for MuseScore already. (I implemented it myself and I'll do the same for Audacity when I get around to it.) To install MuseScore./MuseScore*.AppImage installOur AppRun file intercepts this option and calls a Bash script that copies the AppImage to If you run the command as root (e.g. with To uninstall MuseScore./MuseScore*.AppImage remove # we allow `uninstall` as an alias for `remove`This deletes all the files created by the Why do we provide these options?For the convenience of our users. @TheAssassin mentioned the advantages of using an external tool do the integration. Those advantages are completely valid, but they rely on the user having the external tool. The advantage of self integration is that it doesn't require an external tool. The tradeoffs (in terms of disk space and inability to alter what's inside the AppImage) are no different to any other aspect of AppImage technology. I would argue that self-integration is more in keeping with the AppImage philosophy. The whole point of providing an AppImage is so that app developers don't have to rely on third parties like distributions, package managers, and package maintainers. We don't want to rely on third party integration tools either, which are just as likely to break as our own integration script, if not more so because our script is written for our AppImage and tested with it specifically. Also, when our script does break we can fix them ourselves and release a new version, but we can't fix problems in an external tool. Let users decideJust because app developers don't want their AppImage to rely on external tools doesn't mean that we won't support using external tools as an optional feature. MuseScore's AppImage can do all the following without relying on external tools:
But if some people want to use an external tool to perform those tasks then they are more than welcome to do so! @probonopd said he sees package managers as outdated, but I fully understand why many people prefer to run a command like Same goes for integration and updater tools. Sure, it costs us a few MB to include these in the AppImage (less after compression), but I think it is worth it to maintain independence, which is the best feature of AppImages. Bundling our own tools doesn't prevent people from using external tools if they prefer. Convenience winsI would love to see a universal solution for AppImage self integration, such as an I appreciate this isn't a perfect solution to the integration problem, but it is a valid solution. An imperfect solution that works right now is infinitely more useful than a perfect solution that doesn't exist yet. Ultimately, the quickest way to a perfect solution is to get more apps and users on board with AppImage, as this would give the AppImage project more negotiating power to get your tools built into distributions. And the quickest way to gain users is by providing something that solves their immediate problem. Nothing could be more convenient than having that solution built into the actual AppImages they are already downloading. |
Beta Was this translation helpful? Give feedback.
-
|
I agree. If somebody does create an AppImage package manager then I would want it to be Homebrew-style, where it downloads official AppImages straight from app developers' websites, rather than |
Beta Was this translation helpful? Give feedback.
-
|
Great points. Yes, AppImage is all about freedom, it empowers application authors and end users.
One? Last time I checked there were more than ten... |
Beta Was this translation helpful? Give feedback.
-
Cool, I didn't know! However, most of these appear to be "me too" projects that have fewer than 50 stars on GitHub, and some haven't seen commits in several years. Showing these in the list makes the AppImage format look like it's not very popular, which isn't true. Also, showing so many creates a paradox of choice where users can't decide from so many options and end up avoiding them all. Diversity is good but fragmentation is not! I recommend having a more curated list that just highlights the ones that have gained some traction with the community and are still actively maintained. Right now that would be bauh and zap, and possibly appimage-cli-tool. If you still want to list the others, ideally do so in a second list, possibly on another page even, or at least write the popular ones in bold so they stand out. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed I am always puzzled why everyone always wants to write their own instead of improving an existing one. But who am I to judge which package manager is to be recommended when in fact I created the AppImage format specifically so that you wouldn't need package managers ;-) |
Beta Was this translation helpful? Give feedback.
-
|
@probonopd because it's easy to make a package manager for a single-file executable where there's no dependencies to manage. For simple things, it's significantly easier to start from scratch than trying to figure out how someone else's codebase works. I made one about a year ago (over the course of a week) and decided against publishing it because the codebase was shit and I lost interest in refactoring it, but it worked and that's probably the reason there's so many out there. |
Beta Was this translation helpful? Give feedback.
-
I've been working with AppImage, deb, rpm and flatpak, and I've had an idea.
But first a little story. I discovered let's say a bug in Gnome Software which only displays itself when an rpm (presumably deb also) is installed from file from the command line. The Gnome team were actually very helpful in diagnosing the problem for me, but in conclusion, stated that the issue would not be fixed because they don't want to encourage people to install non-repo software.
Mmmmm... That kind glitched with me because I thought Linux was meant to be about freedom. In fact, I think it very important for users to have the freedom to install software themselves, and for vendors and developers to be able to release software without having to go through repo gatekeepers.
This is the reason why I love AppImage and it gave me an idea, although I would suspect it is has already been thought of...
If I download and use an AppImage that has packaged a desktop file (and possibly metainfo.xml), then presumably it would be possible (and even easy) to add an install command to the AppImage itself, so that if I then wanted to properly install the software, I could type:
This would put the AppImage file itself in
/usr/bin, and add the desktop and metadata appropriately under/usr/share, as well as an icon etc.This would be like having a Windows Setup file which not only installs, but runs the application without installing as the default mode of operation.
The only remaining issue would be to ensure that the user has a clear way to uninstall the application later?
Any thoughts?
PS. I note "AppImage Pool" and have been using it. Love it. But having the ability to install directly from the AppImage itself could be significant?
PS2. Just done a quick search before posting this, and found "AppImageLauncher". Is this relevant to this discussion? Would it be better/simpler to have AppImage be able to install themselves?
Beta Was this translation helpful? Give feedback.
All reactions