Snap/Flatpaks

[rugk]

Providing snaps and/or flatpaks for Linux would be nice and allow you to cover many distros.

[dbrgn]

Or alternatively an AppImage.

[ovalseven8]

I do not really understand AppImage, is not it just a statically linked binary? Why call it "AppImage" then?

[dbrgn]

It contains a (I think mostly readonly) filesystem with all necessary libraries. As far as I remember, the binary is not necessarily static. But I don't remember in detail how it works.

[blizzard4591]

I am currently using CPack to create Debian .deb files, and even that was a much steeper learning curve than I anticipated.
Is there an "easy" tutorial on how to automatically create Snaps, Flatpacks or AppImages?
I will take a look at and play around with https://docs.snapcraft.io/build-snaps/ci-integration in the next weeks.

And if someones is willing to maintain them, I am more than happy to pitch in with hosting or the like.

[dbrgn]

For appimages it's quite simple if you're doing a qt application.

Here's a build script from LibrePCB: https://github.com/LibrePCB/LibrePCB/blob/master/dev/travis/build_appimage.sh It's based on linuxdeployt. It looks like you an also create cross-distro deb and rpm packages with that tool.

[rugk]

https://flatpak.org/hello-world ?

[probonopd]

I do not really understand AppImage, is not it just a statically linked binary? Why call it "AppImage" then?

It is a self-mounting filesystem image that can contain whatever you put inside, like a .dmg disk image on the Mac. Usually people put dynamically linked binaries in there, together with all dependencies and resources the application needs that cannot be expected to be part of every target system in a recent enough version.

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

• Applications packaged as an AppImage can run on many 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
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

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

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

[rugk]

Uhh there is too much optional stuff there in your AppImages. I think AppImages are possibly useful for portable (USB) applications, but for desktop applications I rather want something that auto-updates, obviously has desktop icons and signed updates (important for security reasons!). Having a sandboxed environment is also nice, so far.
Of course also all advantages listed by @probonopd are included, such as cross-distro distribution. As such, in short Flatpak with distribution on https://flathub.org/ would be preferable IMHO (snap provides also much of these, but is Ubuntu-centric, only).

[probonopd]

Flatpak is as much Red Hat centric as Snap is Canonical centric imho. AppImage is a different thing, think of it as "PortableApps for Linux".

[rugk]

It's not, Flatpak is available on much more distros than Snap. AppImage is for portable apps, without an update mechanism and a secure way to deliver those (and first time installs) I cannot consider this for the desktop.

[probonopd]

without an update mechanism

There is an update mechanism. It's called AppImageUpdate, and it's great because it uses binary deltas (think "diff" but for binaries). AppImages can embed update information (to be used by outside updater tools such as AppImageUpdate) or can even embed the updater, making the AppImage self-updateable (by using libappimageupdate).

and a secure way to deliver those (and first time installs)

The most secure way imho is to always get the binaries from the original application author, from the same place where the source code resides. In other words, from https://github.com/blizzard4591/openMittsu/releases.

[conloos]

+1 for a snap

By the way: snap and flatpak are available on many distros e.g snap: https://snapcraft.io/docs/installing-snapd

[HorstBaerbel]

Just my 50ct:
I'd vote for Flatpak over Snap and AppImage, as it is integrated into many distros by default (e.g. Fedora). It is also easily installed in Ubuntu and then provides automatic updates. Flatpak applications start much faster for me than Snap and AppImage packages (probably because of less bloat) and are less likely to have e.g. icon problems.
I removed Snap support in Ubuntu 20.04 altogether in favor of Flatpak and it is working very well for me.

[probonopd]

@HorstBaerbel in my experience, does not run properly e.g., on most Live ISOs.

[HorstBaerbel]

@probonopd Good to know. Not very relevant to openMittsu probably.
I like AppImage but system integration and the lack of automated updates is a no-go for security-critical applications imo. This is because with AppImage it is not as straightforward as with flatpak and snap, at least on Ubuntu (apt install gnome-software-plugin-* and you're done). Also the container / sandbox aspect of snap / flatpak seems important for e.g. openMittsu too...

[probonopd]

Thanks @HorstBaerbel. Everything has pros and cons. Just to set the record right, there is AppImageUpdate and there is even a Qt plugin that you can bundle with your Qt-based application that will make your application self-updateable... with binary delta updates, which means that only the bits that have actually changed need to be downloaded by the user.