Sunset AppImage in favor of Flatpak about wowup HOT 24 OPEN

I am actually very fond of the idea of migrating from AppImage to FlatPak, it's easier to have the application automatically updated on the go and it's the to-go default system to dish out application in almost every single Linux distro. It is true that Canonical (the house behind Ubuntu and it's sister projects) it's trying to stop it at the moment but that's because they want to favor SNAPS, their own internal product, not for AppImages.

AppImages are in my own humble opinion a bit barbaric, you need to open your browser, go to a website and search for a download link of sorts, download it and delete the old stuff. To not talk about the fact that you have all a series of extra steps to make it appear automatically in your application list. I just think it's much better to use something like FlatHub that just automatically updates and maintains everything with each standard system update.

from wowup.

from wowup.

I wanted to comment this would awful. Myself and a lot of others do not use flatpak and snap because of the additional software requirement. You can't give someone either and expect it to work. With appimage you can. They're not comperable formats.

For reference though, it's not something they're unaware of:
AppImage/AppImageKit#1120 and AppImage/AppImageKit#877

from wowup.

This is easily fixed by using a static AppImage runtime that does not require libfuse2 nor 3.

from wowup.

You have a point, but that furthers the urgent need for flatpaks, not as substitutes to appimages for those few peoples that still want to use the Windows system but for all of those that want more homogeneous integration with the common Linux way of installing apps

from wowup.

Flatpak requires a background daemon. It requires a separate installation method from every distro it's used on.

It's literally the worst of all worlds.

I'd honestly use Wine to run the Windows version before I'd use a flatpak. The only thing worse than flatpaks are snaps.

If you're going to use an all-in-one solution, something that requires not only an entire separate software ecosystem from whatever any given machine uses, but also a background daemon to even function seems like it fails at that out the gate.

Lets dispel something here as well, flatpak is not a daemon. It's an application. Just like your distributions package manager.

There are no background services running eating your precious memory cycles unless you explicitly enable them or the Distribution your using sets them up for you. Which flatpak upstream does not have any OFFICIAL daemon projects
Please take some time to understand what your even going to be complaining about, before you complain about it.

Even then AppImage isn't that much better and if anything actually a worse User Experience when both KDE Discover and Gnome software both natively support and integrate flatpak. Your literally running a binary application out of your user's home directory just like flatpak, and manually enabling executable permissions on a file you download is something many users just simply aren';t wanting to deal with, along side the lack of native application menu integration.
of which there are solutionb to the application menu integration but guess what those involve???? Running daemons which you pointed out you simply don't want to do.

Even then, are you willing to build a maintain a native package for your distribution? Most likely not, but I have been wrong about that before.

from wowup.

Nothing. I'm saying flatpak isn't that. That's why while I'm not against it as an option, I'm very against it as a replacement for appimage. It adds an entire ecosystem outside the distro to the mix. That's what the problem is. Say I use all distro provided software, and one flatpak. That's overkill. It's great if that's what you're using a lot of, but look at it from that perspective. A single piece of software requires installing flatpak and all its dependencies.

So your argument is binary count bloat? Please open a terminal and launch Wow using --appimage-extract

That will extract all the contents of the AppImage and drop them into a folder called "squash-fs" I count 4 binaries and 11 libraries all 15 of which can be executed or read independently of each other.
Believe it or not this is the same solution that snap takes, except you dont like the daemon. Thats fine don't use it.

Ultimately though AppImage has a much high barrier to entry than flatpak does. Why do I say this? Because the most popular distros ALREADY ship flatpak on the system (well besides of Ubuntu 23.04).
or is your argument about disk space? Because Then I'd need to remind you that WowUp also ships with the chrome embedded framework in it as it's an electron application. But at the same time, disk space, specifically solid state disk space has actually been really really really cheap lately and is perfectly capable of handling 107MB's

Snap and how canonical used them is bad. They acted akin to a malware vendor in my mind with how they handled certain aspects. I don't want to get into that here, as that's way outside the scope of anything here.

Then why even mention them?

from wowup.

I agree, this should be split to two issues.

1. Adding flatpak
2. Changing the build process for the appimage to use the static runtime here: https://github.com/AppImage/type2-runtime

Doing both should please most if not everyone, especially since as I understand it, the latter can be done using githubs CI tools entirely

from wowup.

I'm not too familiar with the ubuntu eco-system and what kind of packages are considered standard. It does seem that Ubuntu is steering away from Flatpacks though: https://www.phoronix.com/news/Ubuntu-No-Flatpak-By-Default

from wowup.

You can still setup and install flatpak on Ubuntu

https://flatpak.org/setup/Ubuntu

from wowup.

Sure, but:

AppImages rely on libfuse version 2 which has been depreciated

Also goes for Flatpacks if Ubuntu stops providing it as a default

Plus flatpaks natively integrate into the linux desktop much more cleanly than appimages and Ubuntu

It's not natively integrating anymore if you have to first get Flatpacks to work because it's not working by default anymore.

What's the Linux world heading towards if both Flatpacks and AppImage are no longer recommended? That said, I'm trying to find more information about what you mentioned regarding the deprecation, and I can't seem to find anything concrete. Do you have anything to read up on this?

I'm not for or against the idea, I just know that we have a fair amount of Linux users who are used to AppImages.

from wowup.

Flatpak can be built with npm run build:prod && electron-builder build --linux deb. But sandboxing in Flatpak is not so good for WowUp users. As is said in PR#1265:

For any non-standard folder, users will need to use Flatseal to add the appropriate folder to the list with their WoW installation.

Native deb/rpm (electron-builder build --linux deb, electron-builder build --linux rpm) is much simpler compared with Flatpak: double click and install, no runtime, no extra configuration.

from wowup.

AppImages are in my own humble opinion a bit barbaric, you need to open your browser, go to a website and search for a download link of sorts, download it and delete the old stuff.

That is exactly what some users want. (Like "Portable Applications" on Windows.)

So we should not see the different formats as either-or, but as "and". They serve different use cases.

from wowup.

Flatpak requires a background daemon. It requires a separate installation method from every distro it's used on.

It's literally the worst of all worlds.

I'd honestly use Wine to run the Windows version before I'd use a flatpak. The only thing worse than flatpaks are snaps.

If you're going to use an all-in-one solution, something that requires not only an entire separate software ecosystem from whatever any given machine uses, but also a background daemon to even function seems like it fails at that out the gate.

from wowup.

Despite all tho, Flatpak is still the most widely used one and it has the most userbase on Linux too, so at the very least adding it should be a given. As said to probonodb before he has a point so maybe substituting it shouldn't be the case, but definitely adding it as an option.

from wowup.

I'll never argue against adding something as an option. Only if it's a replacement (or worse, the ONLY option) am I against it.

from wowup.

That was not what I intended to type. That was two separate sentences that somehow got merged.

Flatpak requires a background daemon. It requires a separate installation method from every distro it's used on.

Should have said
Snap requires a background daemon and both snap and flatpak use repositories separate from whatever system they're installed on.

The point there was to argue against it being a homogenous solution on literally any distro.

from wowup.

I mean.. the fact that flathub (as an example repo as it's the most used one by flatpak) is universally shared by all distros that use flatpak (even Fedora now has it back enabled by default for example) it's a pretty good example of being a homogenous solution on any distro. Flathub is the solution of the present and the future of Linux.

from wowup.

The point there was to argue against it being a homogenous solution on literally any distro.

Whats wrong with a homogenous solution? Flathub is in fact proof that the community doesn't want that because honestly how many other flatpak repositories do people actually enable? And flatpak was purpose built to have the ability to pull packages from different repositores.

Sure native packages maintained by your distro are the best option, but is WowUp was to support that format they would have to make a package for Ubuntu, another for Debian, another for ArchLinux, another for Fedora, another for openSUSE, anoyther for Solus, and so on.

Oh wait package maintainers exist! They also disappear randomly, often dont push updates in time, or even backport security fixes in time. You'll see application users come to the bug tracker reporting an issue form 4 years ago thats already been fixed, and even package maintainers might not compile the same feature set another paclage mainter would package. Then your distro might ship a different library version than Wow would support.

Snap (which was the first one) literally came into existance as a solution to these issues, but because "Canonical bad" flatpak was made, but then because "Redhat bad" AppImages were made.

Now that doesn';t mean you shouldn't grab WowUps source and package it, that's literally your GNU given right to do so.
WowUp already ships several binaries for 3 Operating System platforms, just HOW MANY PACKAGES do you think WowUp should officially serve? IMHO, just 1.

Dont like flathub? make your own flatpak repository then.

from wowup.

I think something is being lost in translation here.

"Whats wrong with a homogenous solution?"

Nothing. I'm saying flatpak isn't that. That's why while I'm not against it as an option, I'm very against it as a replacement for appimage. It adds an entire ecosystem outside the distro to the mix. That's what the problem is. Say I use all distro provided software, and one flatpak. That's overkill. It's great if that's what you're using a lot of, but look at it from that perspective. A single piece of software requires installing flatpak and all its dependencies.

Snap and how canonical used them is bad. They acted akin to a malware vendor in my mind with how they handled certain aspects. I don't want to get into that here, as that's way outside the scope of anything here.

"Now that doesn';t mean you shouldn't grab WowUps source and package it,"

I'd be thrilled if they released a source package with a makefile. I could work with that.

But my problem comes to what you say here

"HOW MANY PACKAGES do you think WowUp should officially serve? IMHO, just 1."

If it's just one, it shouldn't be one that is so overkill if you're only ever using it for a single piece of software

"Dont like flathub? make your own flatpak repository then."

My point has nothing to do with the specific repository but rather the need of one at all.

from wowup.

Ok, to be completely fair tho, I don't agree that Flatpak is overkill and AppImage isn't. To give a simple example, AppImage requires LibFuse to work out of the box, as probonodb so kindly explained before that can be written into the appimage as a static resource. That sounds fantastic on paper until you realize that Flatpak and AppImage have the same issues but resolve it in two completely different ways.

A WoWUP distributed on (let's say flathub for the sake of simplicity) will indeed require you to have flatpak installed on your system.

A WoWUP disitrbuted on AppImage will have libfuse integrated into itself.

But there isn't just those two hard requirements dedicated to the package manager, there is the entire suite of dependencies that WoWup has itself, example electron etcetera.

In which way does this make a difference then?
If I have 20 apps that require electron and they happen to use all the same version of it, on Flatpak I will have one version of electron installed on my system (used by flatpak) and then shared across all other applications that need it as a dependency. If I have 20 apps that require electron all on the same version while using AppImages I will have 20 exact copies of electron in each one of my images statically linked in them, same goes for 20 different libfuses and so on.

I repeat again, in my book there is no need to remove AppImage support to add Flatpak (the two systems can coexist) but without a doubt with the exception of one's personal preference you can't tell me that if WoWup has to support a single format that should be AppImage and not Flatpak, as that makes absolutely no sense.

from wowup.

"So your argument is binary count bloat?"

No, it's having to subscribe to an entire software ecosystem (or setup and maintain your own repository) to use a single piece of software.

As for when I mentioned how canonical handled snaps

"Then why even mention them?"

That was entirely in response to Snap (which was the first one) literally came into existance as a solution to these issues, but because "Canonical bad" flatpak was made, but then because "Redhat bad" AppImages were made.

Look, here's what I consider good options (and why)

Source tarball releases w/ makefile (I can build it and get on my system however I'd prefer, prefixes, rpaths, configuration flags, etc, can easily grab a new build, or dev build)

Appimage (I can drop the executable in a path of my choosing, and can grab a new release whenever,)

And I understand that snap, flatpak, and appimage are three ways of solving the same problem. In my opinion, snap and flatpak are the worst ways to solve that problem, while appimage comes closest.

Lastly, I want to stress, I'm NOT arguing saying don't do flatpak. I'm arguing saying don't do flatpak instead of a non external repository requiring format. Plus, as other people already mentioned here, you can use a static runtime with appimage, so the whole reason for opening this issue is rather a non-issue, no?

from wowup.

I presume I should add open a new issue since I think we are all generally agreeing the solution should be adding flatpak and not substituting appimage with flatpak. Or at the very least nobody seems to have anything against that.

from wowup.

I made that issue to condense the solution we have generally agreed in here since they diverted so much from what OP has originally asked, if you have some tips or ideas I should mention please help me out in there!

from wowup.