AppImage vs native packages discussion

[robert7]

Copied from #182

@robert7:
Another problem is that for some reason, if the app is started as AppImage, then system theme is not respected - so gui has different fonts/colors. I think this is issue of linuxdeployqt, but maybe it could be useful to track it here as open issue? maybe there is workaround? should I create new issue for that?

@d1vanov
Although I haven't looked at the crash dumps yet, I suspect they have something to do with AppImage packaging. Or are you able to reproduce the crashes with PPA version as well?

About the non-respected system theme - it's an issue of AppImage format itself, not even the one of linuxdeployqt. The only solution the AppImage format has to offer is bundling whatever icon/font theme the app uses with it. I don't really like it and that's exactly why I bothered to create native packages for various distributions. From my POV AppImage in it very nature is a sort of a hack, a short term solution to give something to play with to early adopters while you haven't packaged your app properly. In fact, if problems with AppImage would continue, I might even discontinue distributing it since my time is too limited to come up with various workarounds for its issues.

[d1vanov]

While I did tell you to create separate issues for separate topics, I'm not exactly sure what can we possibly discuss here 😃 Although I am open to the discussion, the comments you copied pretty much sum things up: the only way for an AppImage to look completely natively is to bundle icons/fonts/whatever else from the target distribution on which the app is meant to look natively. If you are interested in learning more about it, have a look at probonopd/linuxdeployqt#60.

[robert7]

sorry I copied the context, because I wanted to write my reply and did not wanted to mix the issues (I'm out of time for today)
my POV is different, but from the linked issue I see, that the themeing problem is actually more difficult then I originally thought

[robert7]

My original indent was, that we can discuss various pros/cons of the AppImage packaging and could be that from the discussion, we get something useful. But if your view are already very strict, then this has no sense and you may close the ticket.

So far I have only a little practical experience in use of AppImage format. Also I din't know, that the "theme-ing" problem is so difficult (like it seems from the attached issuse) and I agree that copying all possible themes in the AppImage seems nonsense. Same for spending too much time investigating this. Basically in the current stage, I don't see the "theme problem" as very important.

Beside that, from my viewpoint I see AppImage as clear advantage as it allows to:
1, use one binary including all dependencies for all users of all recent linux distributions.
2, you can use newest libraries and not be stuck with X years old libraries for various packagings
3, you don't need so many #ifdefs in code
4, I think using many combinations of app binary multiplied by various versions of dependencies greatly increases the complexity

Just in the tests yesterday I used 4 combinations (2x version from PPA and 2x versions of AppImage) - all had different problems and you saw it was not difficult to crash the app. This added complexity could be OK, if there would be a team of 10 developers. But as you self said with the limited time available, this could be too much of burden.

[d1vanov]

Well, I have to admit that my views on AppImage are indeed strict enough. I see its strengths but I can also clearly see its weaknesses. In my view this format is good enough as a fallback for users of distros for which no native package is available. It can also be used for utilitarian purposes like to test some new or experimental version quickly without installation. However, by its very nature AppImage format cannot beat native packages in a number of topics including

1. Integration with the rest of the desktop, in various aspects, including theme-ing.
2. Security through the use of shared libraries. When several applications use the same shared library, a security threat can be fixed within that shared library and all applications using it would receive the security fix without any single update to the applications itself. With AppImages you would have to update each and every single AppImage containing that shared library to be safe.
3. Security through the centralized updates. Applications coming from distros are (supposed to be) tested by distro maintainers so at least some guard from malware is present. AppImages can be distributed by anyone on the Internet so trusting to the unknown distributor is your only option in fact.

Of couse, there are a ton of issues with native distro-specific packages

1. Their great numbers and associated complications with each of them
2. Different versions of libraries and stuff in different distros due to which some oldest supported version should be used
3. Updates from distro packagers generally come to users when distro packagers deem necessary, not when the developer would like.
4. And many other issues.

As I see it, some kind of merge should occur in future between the old way of packaging and the "new way" which is more developer-friendly. In fact, flatpak looks quite interesting as it somewhat merges the use of shared libraries from native packages and the ability to package app-specific libraries within a single binary. It is important for such a packaging format to be supported by distributions so that it at least is taken into account by distro maintainers. No distros care a single bit of AppImages: many issues with AppImage packaging arise from the fact that distros change something which AppImage format assumes won't change ever, for example, the ABI stability of OpenSSL - probonopd/linuxdeployqt#209. Flatpak, on the other hand, is already supported by some app stores such as Plasma Discover. For now I decided to delay packaging to flatpak as the "central repository" of flathub.org accepts stable releases of packages, not alpha and experimental versions. And Quentier is still in alpha state so too early for flathub.

[robert7]

OK.
Just for point "3" - the security is same level, if you install from PPA. Even then I personally would prefer AppImage as it doesn't need root to install.