New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide AppImage as a long-term replacement for ppa, deb, rpm, etc. #469

Closed
overheadhunter opened this Issue Mar 16, 2017 · 23 comments

Comments

Projects
None yet
@overheadhunter
Copy link
Member

overheadhunter commented Mar 16, 2017

To simplify deployment on Linux distributions and provide a better isolation from system dependencies, we should consider providing an AppImage instead of all the system-specific formats.

We can then still create installer-scripts via PPA, such as the one for Oracle Java by webupd8team.

@overheadhunter overheadhunter added this to the 1.x milestone Mar 16, 2017

@markuskreusch

This comment has been minimized.

Copy link
Contributor

markuskreusch commented Mar 17, 2017

Looks promising, worth a try.

One thing from the AppImage description:

  • Optional(!) desktop integration with appimaged

so users will still have to install a service using their package manager to get features like, menu icons etc. But that should not be a problem in general, but may only lead to some "I do not want to use appimaged but like my package manager more debates" but I think less overhead for linux builds is worth it. Anybody interessted could still provide native linux packages. In addition we will finally bundle the JRE for linux as well which is a good idea.

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Mar 17, 2017

In addition we will finally bundle the JRE for linux as well which is a good idea

Exactly. No more Oracle JDK updates screwing up the JCE policy files. But the key size limitations will be gone with Java 9 anyway. Nevertheless handy to have all dependencies under control.

@ksthiele

This comment has been minimized.

Copy link

ksthiele commented Apr 5, 2017

Are Snap and Flatpak versions planned? They are easier to update, sandboxed by default and can be rolled back if something goes wrong.

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Apr 5, 2017

@ksthiele we haven't investigated yet. Any system that allows us to provide one installer for multiple distributions would be great. If you have experience with one of them, feel free to post any advice.

@probonopd

This comment has been minimized.

Copy link

probonopd commented Apr 5, 2017

Providing an AppImage would have, among others, these advantages:

  • Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
  • One app = one file = super simple for users: just download one AppImage file, make it executable, and run
  • No unpacking or installation necessary
  • No root needed
  • No system libraries changed
  • Works out of the box, no installation of runtimes needed
  • Optional desktop integration with appimaged
  • Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
  • Can optionally GPG2-sign your AppImages (inside the file)
  • Works on Live ISOs
  • Can use the same AppImages when dual-booting multiple distributions

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

@sdeleuze

This comment has been minimized.

Copy link

sdeleuze commented Apr 8, 2017

+1 for Snap and Flatpak packages, I am less convinced by AppImage (not sanboxed).

@probonopd

This comment has been minimized.

Copy link

probonopd commented Apr 8, 2017

AppImage (not sanboxed)

@sdeleuze check out Firejail, it has native AppImage support.

@sdeleuze

This comment has been minimized.

Copy link

sdeleuze commented Apr 8, 2017

I know, but that's less integrated, not sure this is a good bet in the long run to follow that strategy, so I would bet more on Snap or Flatpak. That's just an educated guess, I am not an expert of these 3 solutions. In any case, providing one of those would be nice.

@probonopd

This comment has been minimized.

Copy link

probonopd commented Apr 8, 2017

There is nothing to "bet" with AppImage, it works today and it doesn't need specific support from the distributions. It does what you make it do. After all, it is just a self-mounting filesystem image that runs what you put inside.

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Mar 22, 2018

After taking a closer look at AppImage, Snap and Flatpak, we decided to use AppImage. We will automate the build steps using a new repo: cryptomator/cryptomator-linux.

overheadhunter added a commit that referenced this issue Mar 23, 2018

@overheadhunter overheadhunter modified the milestones: 1.x, 1.4.0 Mar 23, 2018

@sqrt

This comment has been minimized.

Copy link

sqrt commented May 10, 2018

Please reconsider this decision. AppImage doesn't feel native at all, and I avoided any apps that used it in the past. Flatpak/snap provides much better system integration, usability and updateability. AppImage is certainly easier for you, but the user experience is much worse.

@probonopd

This comment has been minimized.

Copy link

probonopd commented May 10, 2018

tl;dr: It's OK to have a personal opinion but please don't phrase it as an universal truth.

This is what Flatpak files look like on the server:

dc12go3x0aaekbx

This is what AppImages look like:

dc12usqw0aa3tki

Now, which one is friendlier? Which one can you easily download using a browser, carry with you on an USB stick, and run without the need for installation?

Snappy works better for me, especially on newer versions of Ubuntu; but it is not available by default in many other distributions including CentOS and Fedora.

AppImage doesn't feel native at all

Why? The "one app = one file" approach makes AppImages"native" on any Linux distribution, as it they can be "managed" by the native file manager without interfering with the core OS.

I avoided any apps that used it in the past

So? I have been actively looking for them. Matter of personal preference and needs...

Flatpak/snap provides much better system integration

What if you don't want system integration, for example because you want to run many versions of the same application in parallel, and the same set of applications on multiple different distributions?

usability

Download a single file, make it executable, and run it. No installation! No root! No package manager or store! There is no better usability than this, in my opinion. It's almost as good as app handling on the Mac.

and updateability

Do you know AppImageUpdate binary delta updates? Apparently not.

AppImage is certainly easier for you, but the user experience is much worse.

Disagree.

@dietrichstats

This comment has been minimized.

Copy link

dietrichstats commented May 28, 2018

This is what Flatpak files look like on the server:

Maybe the example you give is a little bit skewed, anyway, how it looks on the server is not so relevant if you use a modern web. Look for example how flathub or snapcraft store works.

Now, which one is friendlier? Which one can you easily download using a browser, carry with you on an USB stick, and run without the need for installation?

That is not synonymous with friendly, not unless you are purposely looking for a windows-like portable application. For current standards based on mobile operating systems, being able to easily install an application from a software store is friendlier than "Download | add execute permissions | execute" as long as the app automatically generates a .desktop file.

but it is not available by default in many other distributions including CentOS and Fedora

Are you referring to installed by default? Because snapd is easily available for many distributions, but not with the best compatibility and personally I question its universality. Flatpak is available in official repos of many distros and in the case of Ubuntu a well maintained PPA. On the other hand, side additional functions like appimaged that you label as optional, but it is very desirable for an end user, it is only available on the author's website after a small search (I would encourage devs to use AppImage to recommend this utility IMHO)

What if you don't want system integration, for example because you want to run many versions of the same application in parallel, and the same set of applications on multiple different distributions?

Those use cases are covered by both snappy and flatpak

It's almost as good as app handling on the Mac

That "almost" makes the difference. In macOS all applications are signed (more trustly, again optional in appimage), the apps use an "installation wizard" and also have integration with the software store, etc.

If you believe that integration with a software store is not important, at least flatpak covers the use case to distribute your software independently, eg JASP (with flatpak you can also install applications without the need for root)

Anyway, the cryptomator authors have already made their decision. Here I simply leave my opinion and I agree with @sqrt .

@yassir-a-p

This comment has been minimized.

Copy link

yassir-a-p commented Sep 26, 2018

Hi, I know there is 1.4 AppImage beta already, but as a non-tester and non-developer, I only use stable releases for my data.
I come here just to ask if dev would like to build an AppImage of the latest stable release.

Also I want to show my usage case with using AppImage that supports the usage of it:
I use 2FAuth on every online account, and they got backup codes. In case I lose my phone, I need the backup codes.
But it's not secure to just print them on paper and carry them physically "naked". So get them encrypted codes on thumb drive is more efficient for me. Then if I need them, I just have to use an AppImage from my thumb drive and decrypt the backup codes anywhere i want.

Surely I don't want to discourage the old package system, or the Flatpak and Snap package. But in my case, AppImage will have its advantages at its best.
Cheers.

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Sep 28, 2018

@yassir-a-p Adjusting 1.3.x to the new CI pipelines we use for the AppImage build will take us longer than releasing 1.4.0. Looking at the issues for 1.4.0 I think we‘re about to release within 2-3 weeks.

@e-alfred

This comment has been minimized.

Copy link

e-alfred commented Nov 16, 2018

How does the Cryptomator AppImage release fit into the desktop with menus etc.? Can you add an option install it into the menus on first start like the app updater?

@njmckenzie

This comment has been minimized.

Copy link

njmckenzie commented Nov 16, 2018

How does the Cryptomator AppImage release fit into the desktop with menus etc.? Can you add an option install it into the menus on first start like the app updater?

You should be able to do this with appimaged or appimagelauncher. The only reason I say should is that on ubuntu 18.04, bits of the desktop or menu integration are problematic (but not just for cryptomator or AppImages). Addition to the menu on first start usually works with either of these options but not always. Changing the menu folder can be somewhat problematic (creates duplicate menu folders).

FYI - with appimagelauncher, use the deb file per the readme on the website

@probonopd

This comment has been minimized.

Copy link

probonopd commented Nov 17, 2018

The appimage version of appimagelauncher didn't have enough permissions.

Are you aware of this @TheAssassin?

@TheAssassin

This comment has been minimized.

Copy link

TheAssassin commented Nov 17, 2018

FYI - with appimagelauncher, the system integration functions only worked when I used the deb package. The appimage version of appimagelauncher didn't have enough permissions.

I have no clue what you are talking about. The AppImage itself is only there to demonstrate the UI. AppImageLauncher must be installed into the system for any further action, as it deeply integrates in the system, and the AppImage sets up that integration in the exact same way as the system packages. Please read the README, it clearly states this.

Most people understand this (fans of rtfm, I guess), but ocassionally people complain the AppImage "doesn't work". I will probably have to remove the AppImages from the release page to avoid further confusion.

@njmckenzie

This comment has been minimized.

Copy link

njmckenzie commented Nov 17, 2018

@TheAssassin - my sentence was just an inelegant way of saying that they need to use the deb file. Your readme says this but many people don't start with that.

@TheAssassin

This comment has been minimized.

Copy link

TheAssassin commented Nov 17, 2018

I see. I'll remove the AppImages later. Thanks for the input.

@probonopd

This comment has been minimized.

Copy link

probonopd commented Nov 18, 2018

What is the actual issue and how can it be solved, so that the AppImage works? Can't we just run it with sudo?

@TheAssassin

This comment has been minimized.

Copy link

TheAssassin commented Nov 18, 2018

The integration itself should work fine (with user permissions), it's using libappimage internally, and doesn't hack any incompatible paths into the installed desktop file. But to make use of the entire AppImageLauncher feature set, an installation is required. Please see the README and wiki pages, I don't want to explain that yet again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment