Moving to Appimage

[mirkobrombin]

The second version for Bottles is almost ready to release the first Release Candidate.

This version was initially designed to then be distributed as Flatpak. There are several reasons that led me to choose Appimage as the distribution format instead.

First of all, having to depend on a system (Flatpak) that not all distributions integrate as standard yet. This could lead to the user having to install and configure it manually, although setting it up takes only a few minutes.

Secondly, the weight problems of the Flatpak compared to the Appimage.

Finally, while the Flathub repository is curated and well maintained, we don't want to official depend on repositories for distribution.

Here one of the fundamental aspects of Appimage takes over: compactness. It is a single file that is easy to download, run, update and remove. There are no centralized systems, the user will only have to download a single file and run it. That's all. Incredible.

So only Appimage?

No. Appimage is the official package system we have chosen to distribute Bottles. This is a community driven project and anyone who would like to collaborate to create, manage and distribute repositories and other packages (like .deb, .rpm, flatpak, snap, aur, ..) are welcome.

Maintaining multiple packages and repositories is hard enough.

[mirkobrombin]

Updated Appimages can be found here: https://github.com/bottlesdevs/Bottles/releases

[hezral]

Any chance you can share how you did this? I can see travisci and github workflows just cant figure out its all tied together

[mirkobrombin]

Any chance you can share how you did this? I can see travisci and github workflows just cant figure out its all tied together

We are currently using Travis to create the appimage for each commit. We would like to migrate to GitHub actions but we haven't finished the work yet so we will still use Travis.

The process is quite simple, you find all the steps in the .travis.yml file.

[hezral]

Thanks for pointing to the right direction. I'll focus on Travis for now, will keep an eye on this :)

[francescomasala]

Thanks for pointing to the right direction. I'll focus on Travis for now, will keep an eye on this :)

Fixed GitHub CI with commit 176d9f8

Fixed Travis CI with commit 4f0ad02

You can find all the commands we used (separated by steps) in the github actions configuration file

[mirkobrombin]

Thanks for pointing to the right direction. I'll focus on Travis for now, will keep an eye on this :)

Fixed GitHub CI with commit 176d9f8

Fixed Travis CI with commit 4f0ad02

You can find all the commands we used (separated by steps) in the github actions configuration file

But we are going to only use Travis for Bottles. Maybe GitHub Actions can be used for wine builds.

[AkechiShiro]

Is it okay if I submit to this AppImage kinda of list repo the release AppImage of Bottles ?

[mirkobrombin]

We have been releasing many versions in the last month but have reached a very stable beta point. I believe you can do it.

[AkechiShiro]

I've done that, but there seems to be an issue with the build test :

===========================================
============= TRYING TO RUN ===============
===========================================
/tmp/.mount_BeingT2Prewj/AppRun: Bourne-Again shell script, ASCII text executable
-rwxrwxr-x 1 root root 1.5K Dec 23 18:00 /tmp/.mount_BeingT2Prewj/AppRun
kernel.unprivileged_userns_clone = 1
Error: cannot configure loopback device
NUMBER_OF_WINDOWS: 0
ERROR: Could not find a single window on screen :-(
IceWM: using /home/travis/.icewm for private configuration files
convert: unable to read X window image `0x200011': Resource temporarily unavailable @ error/xwindow.c/XImportImage/5005.
convert: no images defined `database/Bottles/screenshot.png' @ error/convert.c/ConvertImageCommand/3210.
code/worker.sh: line 293: kill: (9219) - No such process
The command "if [ x"$FILES" != x ] ; then for FILE in $FILES ; do echo "$FILE" ; bash -e code/worker.sh $(readlink -f "$FILE") ; done ; fi" exited with 1.

Here is the whole build logs.

There was this Warning that I feel was just a quick notice about image file formats, but I didn't see anything else relevant :

WARNING: Icon is not in PNG format. It should be so that it can be used as a thumbnail

Does the problem relate to the fact that there is no X window ??

This file descirbes how the AppImage are generated ?

[mirkobrombin]

The correct file is .travis.

They use Travis to test the AppImage but that I know of Travis hasn't an X server on it. I should investigate.

[liferooter]

First of all, having to depend on a system (Flatpak) that not all distributions integrate as standard yet. This could lead to the user having to install and configure it manually, although setting it up takes only a few minutes.

Most distros and major DEs supports Flatpak out of the box. You have to just install your app from store or flathub.org if you prefer GUI or just enable Flathub (it's usually already done) and run flatpak install bottles. If you don't have Flatpak in your system, you have to install it. After that, you'll get updatable application tested in its environment with icon in your application menu.

AppImage is also supported by most distros. It needs only FUSE support. It also might be not installed and user might has to install it. After all, AppImage don't create an icon for app menu so user has to set it up manually.

There are no centralized systems, the user will only have to download a single file and run it. That's all. Incredible.

It's not so cool as you think. First of all, downloaded file can't be just ran. It doesn't have execute permission, so user have to add it manually. Secondly, user looses an ability to update your application. They have to go to your GitHub sometimes to find out if there are any updates. Thirdly, as I already told, user don't have this app installed and has to manually find and open this file any time it's needed.

Here one of the fundamental aspects of Appimage takes over: compactness. It is a single file that is easy to download, run, update and remove.

First of all, it's compact by number of files but not by its weight. Flatpak uses runtimes shared by all applications so you don't have to ship GTK and other basic dependencies with your application. Secondly, AppImage is not easier to download (seek file in GitHub releases VS just press "Install" in application store such as GNOME Software or run flatpak install bottles), run (press an icon in app menu VS find AppImage file in file manager and open it) and update (seek file in GitHub releases VS update with other Flatpak apps with application store or flatpak upgrade).

Finally, while the Flathub repository is curated and well maintained, we don't want to official depend on repositories for distribution.

So you make it harder for user to find and install your application. Also depending on repositories in case of Flatpak is a price for cross-distributive distribution without shipping all your dependencies with you. Flatpak's runtimes allows you to don't depend on distros, software or software versions. For example, when I installed Bottles from Flatpak on my Fedora 34, all works good not depending on GNOME version or graphic system because of it. Now when I use your AppImage app fails to start because of using gsettings from older GNOME and becase I use Wayland. Flatpak solves it by using runtime and disable Wayland access in manifest.

So after all, do you really think that AppImage is better?

[pyrotek45]

I think the flatpak would be the best methods for the reasons mentioned above too. appimage didn't work out of the box for me either, where as the flatpak version did.

[mirkobrombin]

First of all, having to depend on a system (Flatpak) that not all distributions integrate as standard yet. This could lead to the user having to install and configure it manually, although setting it up takes only a few minutes.

Most distros and major DEs supports Flatpak out of the box. You have to just install your app from store or flathub.org if you prefer GUI or just enable Flathub (it's usually already done) and run flatpak install bottles. If you don't have Flatpak in your system, you have to install it. After that, you'll get updatable application tested in its environment with icon in your application menu.

AppImage is also supported by most distros. It needs only FUSE support. It also might be not installed and user might has to install it. After all, AppImage don't create an icon for app menu so user has to set it up manually.

There are no centralized systems, the user will only have to download a single file and run it. That's all. Incredible.

It's not so cool as you think. First of all, downloaded file can't be just ran. It doesn't have execute permission, so user have to add it manually. Secondly, user looses an ability to update your application. They have to go to your GitHub sometimes to find out if there are any updates. Thirdly, as I already told, user don't have this app installed and has to manually find and open this file any time it's needed.

Here one of the fundamental aspects of Appimage takes over: compactness. It is a single file that is easy to download, run, update and remove.

First of all, it's compact by number of files but not by its weight. Flatpak uses runtimes shared by all applications so you don't have to ship GTK and other basic dependencies with your application. Secondly, AppImage is not easier to download (seek file in GitHub releases VS just press "Install" in application store such as GNOME Software or run flatpak install bottles), run (press an icon in app menu VS find AppImage file in file manager and open it) and update (seek file in GitHub releases VS update with other Flatpak apps with application store or flatpak upgrade).

Finally, while the Flathub repository is curated and well maintained, we don't want to official depend on repositories for distribution.

So you make it harder for user to find and install your application. Also depending on repositories in case of Flatpak is a price for cross-distributive distribution without shipping all your dependencies with you. Flatpak's runtimes allows you to don't depend on distros, software or software versions. For example, when I installed Bottles from Flatpak on my Fedora 34, all works good not depending on GNOME version or graphic system because of it. Now when I use your AppImage app fails to start because of using gsettings from older GNOME and becase I use Wayland. Flatpak solves it by using runtime and disable Wayland access in manifest.

So after all, do you really think that AppImage is better?

Assuming that this issue is very very old and that over time we have added Flatpak, Snap and Deb to the official distribution methods, as well as AUR, Fedora, Void and Nix among those maintained by the community.

Flatpak is certainly the format that has been most adopted by distributions but it is not ready to use as you say. Wanting to give an example of distributions (important, widely used) in which there is no default Flatpak:

• Ubuntu
• many of the Ubuntu flavors (Kubuntu is an example if something hasn't changed)
• Debian
• Solus (moving towards snap packs as far as I know)

these too (which are aimed at advanced users so they know what they need to do, but it's not out of the box anyway):

• Arch Linux
• Void Linux
• NixOS

Many distributions have Flatpak by default but do not have Flathub, the repo we use to distribute Bottles. So the user will still have to take some steps to install our software (all clicks but it also depends on how the store behaves because very often or almost always, once Flathub has been added you have to restart the system or stop the GNOME Software process to make them find it).

Yours are certainly all very valid points but to the question: "So after all, do you really think that AppImage is better" I answer yes. Considering the facts, what a package has to do is be distributed and easily available everywhere and in fact Appimage is the best method in terms of portability and large-scale distribution.

The first step of a novice user (especially if he comes from Windows, therefore a part of Bottles users as the rest is mostly advanced and does not arise these problems) is to go to the product site and download it. If you are a new user and you install Ubuntu for example (due to the strong image it has it is often one of the first choices of new users) and you get to know our software, if you open the snap store you obviously do not find the flatpak but the snaps. So the user goes to the site and you think it is better to tell him to open the terminal, install a package, reboot, add the remote flathub, install bottles (always from the terminal because he should install gnome-software and replace the snap store, losing the only frontend it has to manage snaps)? Or do you think it's better to download a file, make it executable, and then run it?

I don't think the perfect package exists. As a user I have preferences, as a developer I have others, but we also have to think about the end user and how it is best to reach him. Assuming Flatpak is everywhere and Flathub is equally everywhere is wrong IMHO.

I understand what you say about updating, distribution and everything in between and that is why over time we have also adopted other official formats such as Flatpak, Snap, Deb and others maintained by the community such as AUR and Fedora.