Appimage/Flatpak releases

[bgeschka]

Hi all, i see issues when running the gns3-gui on archlinux and most probably other distro's too. Several times i tried to convince people to use gns3-gui against e.g. my gns3-server or their own i ran into issues of either:

• Versions of the Gui from distroX default repository is not compatible with the dedicated server
• gns3-gui is not available on distroX's default repos at all, and require adding other repo's
• trying to get the servers versions gui running on distroX may results in python version missmatching and breaking mainstream packages

If we got a dedicated machine in our lan with gns3-server, we can have that machine rot in any weird state it wants, as long as gns3-server runs fine as no one has to deal with it directly but only through the gui. At the moment its more feasible for me deploying the windows build with wine for compatibility reasons.

Can we have AppImage or Flatpack or a similar solution for the gns3-gui including python dependencies (maybe QT and maybe Wireshark versions known to work)? I know the images might get probably huge with the dependencies, but then this would be a portable solution to run on probably any desktop linux without major pains and without breaking stuff.

I know there's things link python virtualenv and other ways to get it running, but most people just won't spend the time getting all of this together, nor do i want to have to do this when trying to get people use it on their machines.

Anyways thanks for the awesome project and keep up the good work :)

[grossmj]

Thanks for posting this. Appimage is definitely something we would like to add :+1:

[ycharbi]

Yes, Appimage is a best choice ! Thank you for what you're doing! GNS3 is a really good tool :clap:.

[PranavBhattarai]

@grossmj I don't want to create a new GitHub issue but can u please provide Snap.

snap install gns3 would have been great to have.

Since according to Canonical, PPA is the worst thing they created because they bundle all unnecessary dependencies which is what Flatpak is doing right now.

(This doesn't mean I am saying, "Don't make flatpak packages. I don't like flatpak, etc.".)

[grossmj]

@PranavBhattarai thanks, I am going to check it out soon since we have issues building a classic Debian package for Ubuntu 20.04 LTS: https://github.com/GNS3/gns3-server/issues/1746

[ycharbi]

hello, I never make appimage but I'd like to try it. What is the method you use to compile GNS3 from sources ? I feel it's important to make this type of package. If I can get something done, I think it could help the problem.

[35609902357]

With the release of Debian 11 this issue has become very relevant. Installation instructions for Debian 10 are lengthy and complicated compared to a Flatpak and AppImage, and since there's the aforementioned building issue on Ubuntu this might be the chance to finally switch to a universal package manager. This would certainly spread the usage of this piece of software around all the Arch, Fedora, OpenSUSE and minor distros users. Flatpak and AppImage should be considered over Snap anyway because the latter has ethical issues being Canonical's proprietary system and has lots of functional issues on non-Ubuntu distros whereas Flatpak and AppImage are fully open-source and supported more and better than Snap.

[grossmj]

Thanks for your input. I tried Snap and found it overly complicated, I prefer the simplicity of AppImage. Do you have a preference between Flatpak and AppImage?

[ycharbi]

Je préfère de très loin Appimage. Ce système n'impose pas de dépendances côté client et un simple copier/coller depuis un dépôt HTTP ou une clé USB permet "d'installer" l'application.

Avec Flatpak il faut installer les outils et charger des "runtime" qui sont d'une lourdeur incroyable (une pensée à ceux qui ont l'ADSL...). On se retrouve avec un disque (souvent SSD où les Go coûtent cher) remplis de dépendances inutiles pour juste utiliser une application (j'ai déjà eu un traitement de texte à plus d'un giga octet avec Flatpak). De plus, si on utilise une distribution qui ne fournis pas Flatpak, l'application sera inutilisable, ce qui n'est pas le cas avec Appimage. Enfin, lorsque l'on veut un système minimaliste, Flatpak brise définitivement tous nos efforts par les simples défauts que j'ai énoncé plus haut. Non clairement, Appimage est vraiment mieux. Il faudra simplement penser à livrer un ".desktop" avec pour avoir le raccourci dans l'interface graphique.

---

I much prefer Appimage. This system does not impose any client-side dependencies and a simple copy/paste from an HTTP repository or a USB key allows to "install" the application.

With Flatpak, you have to install the tools and load the "runtime", which are incredibly heavy (a thought to those who have ADSL...). You end up with a disk (often SSD where GB are expensive) full of useless dependencies just to use an application (I already had a word processor with more than one gigabyte with Flatpak). Moreover, if you use a distribution that does not provide Flatpak, the application will be unusable, which is not the case with Appimage. Finally, when you want a minimalist system, Flatpak definitely breaks all your efforts by the simple flaws I stated above. No, clearly, Appimage is much better. You'll just have to think about delivering a ".desktop" with it to have the shortcut in the GUI.

[35609902357]

@grossmj Both Flatpaks and AppImages have their pros and cons. While it's true Flatpaks require a few hundreds MB of runtime, this is only for the first one, the following Flatpaks you install will be light as you already have the runtime installed. In the long run AppImages require more data to download because everytime they are updated you need to download the whole app and the bundled libraries for each application. Flatpaks are also sandboxed by default, AppImages need to be run on top of firejail and that often doesn't work (as in they don't launch), and even when it works Flatpak's bubblewrap is a superior sandbox. Having it listed in Flathub will also give the project more visibility. On their side AppImages are like Windows portable applications, they are download and run. They also work more reliably than Flatpaks. I think you should provide both, just make sure to ship Flatpak via Flathub and to provide a self-installing .desktop file and auto-update feature for AppImage (i.e. the AppImage should be named something like GNS3.AppImage, not GNS3_v_x.xx.xx.AppImage otherwise the .desktop file will have to be manually changed after every update). You should also make reproducible builds. Your users will then decide which one to use. Even though it might seem daunting to provide two different packaging systems keep in mind you won't have to maintain the Debian repos and the PPAs for present and past releases.

[arrowmaster]

This needs more attention as the jammy ppa is incompatible with Debian Bookworm because the .dpkg packages are now compressed with zstd and the focal packages are built for a too old version of python to work. The only current way to install on Debian Bookworm is via pip.