Please use a format other than AppImage -> namely FlatPak

RichardJECooke commented 11 months ago

Your idea

AppImage is awful. In Ubuntu/Gnome/Debian the application:

is not available in system app menu
does not have an icon
does not ship with Musesounds
cannot be added to favourites in the taskbar
has to be manually downloaded in a browser, so you can't run an install script to install Musescore in a new system automatically with user input

Rather use snap or flatpak please, which have flawless system integration (I know there are snap and flatpak versions, but they are community maintained, and are out of date or just plain don't work - AppImage is the only official format made my Musescore.org on Linux)

Problem to be solved

As above

Prior art

No

Additional context

No

Jojo-Schmitz commented 11 months ago

Wouldn't "installing" the AppImage using the install commandline option fix this or at least parts of it?

RichardJECooke commented 11 months ago

How do I do this please? When I searched for what an appimage is, the Internet and chatgpt told me to download it, make it executable, and run it. That it's just basically a zipped folder of an entire application.

Jojo-Schmitz commented 11 months ago

RTFM? https://musescore.org/en/handbook/4/download-and-installation#Install

cbjeukendrup commented 11 months ago

does not ship with Musesounds

Muse Sounds always needs to be installed separately, because it can't be packaged with a GPL3-licensed program which MuseScore is

[for the record, after this comment there was another comment which I later deleted about that questions are better asked on MuseScore.org]

RichardJECooke commented 11 months ago

@cbjeukendrup Thanks. I saw there is a 'feature request' option under issues so I thought this was the place to do it. You might want to remove it so as not to confuse users.

cbjeukendrup commented 11 months ago

@RichardJECooke It's fine; feature requests are welcome here, but it's not an ideal place for long question/answer discussions because then the developers will need to go through all of that to see what's useful info for them and what not.

Now to give you an actual reply: I understand very well that AppImage is not really ideal from the user's point of view. As a Mac user I like the simplicity of the App Store very much, and I imagine FlatPack and Snap on the respective Linux distros must be similarly nice. But from a developer point of view, AppImage is very convenient because you can do the work only once and still support quite a lot of Linux distros. Other ways of packaging/distributing are often limited to a few distros, which would mean that we need to create and maintain packages for a lot of different systems. That's a bit prone to errors, and more importantly we wouldn't really like to spend our manpower on that. Choosing one system doesn't really work; the Muse Sounds team initially chose one popular way of packaging, but then immediately people complained that they need other ways too.

If other people want to create MuseScore packages for certain systems, we're happy with that, and if we need to make some changes in order to facilitate that, we're happy to do so; but I don't expect we will create packages for other packaging systems ourselves in the near future.

bkunda commented 11 months ago

Agree with @cbjeukendrup's explanation here, so closing this issue for now.

AdrianVovk commented 10 months ago

Hello! Just gonna butt in here w/ some technical background as to why AppImage is a bad idea for your stated goals, aside from it just being a terrible UX for users. Hopefully I can convince you to at least re-open this issue

Linux has 3 "universal" packaging formats. Of these formats, there is exactly one that is actually cross-distro: Flatpak.

I'll briefly touch on "why not snap" before going into the more severe topic of "why not AppImage". In short, because Snap doesn't actually work right on many distros. Its sandboxing capabilities require certain deep integrations with the OS that only Ubuntu provides, like using AppArmor and various patches throughout the system. Many popular distros, like Fedora, instead use selinux or lack the patches required all over the place to support Snap, and so Snaps run unconfined. Canonical, the parent company of Ubuntu, is solely in charge of Snap's server backend, which means that Snap is basically vendor locked-in to Canonical and Ubuntu. For this reason, there is little community trust in Snap among members of other distros, and there is no incentive to actually do the work to support Snap correctly. Finally, since there is so little community trust, Snap isn't well supported by the desktop environments: Canonical themselves have to maintain support for Snap in their forks of DE settings apps, and they also maintain their own app store frontends for Snap. I would avoid Snap just because of the sheer lack of community buy-in.

That leaves AppImage and Flatpak, both of which promise to provide cross-distro packaging, but only one of which could actually possibly deliver. AppImage is, at its core, a complete misunderstanding (at best) of how to link libraries in a cross-distro compatible way. The claim is that that by rolling everything into an AppImage, you get to support all/most distros, because you ship all your libraries. Except that is blatantly false: AppImages still link against the system's glibc, and other libraries like libfuse2 (which is unmaintained). There is a reason for the recommendation that you build your AppImages on the absolute oldest LTS supported distro you can find anywhere: otherwise, your AppImage will link against a newer version of glibc than your consumers may have, and so you will be unable to run the AppImage on those older LTS distros. This, of course, increases your maintenance burden because you're stuck compiling your app images on ancient builds of Linux distros from years ago. I don't really know what else to say about it: AppImages do NOT bundle all the dependencies they need, and so that means that you are always going to be stuck with weird distro-specific edge case bugs due to ABI incompatibilities between distros. An AppImage's reliance on deprecated libraries like fuse2 will only become a bigger problem over time (issue upstream, where they decided not to port to fuse3)

I'd be surprised if you haven't run into much of this yet. If you're not hearing about it, then I'd guess it's likely that:

1) People aren't using the AppImage in the first place, because very few think to go to the project website to download an executable on Linux 2) People are trying the AppImage, but it immediately crashes on startup (if, for example, the user is on a modern-ish distro like Ubuntu 22.04 that doesn't ship libraries like fuse2 out of the box and thus cannot run AppImages w/o manual commandline intervention). People then try a more sensible packaging format and find that everything works great and thus don't bother filing bugs. 3) You've just been ignoring the issues because you never intended to support the "weird" distros where everything breaks down. I understand it's not on the app to support all the distros, but my point is that AppImage makes you do that anyway, just like traditional Linux packaging does, just in a more roundabout way. This is a limitation of AppImage, NOT of Linux app distribution. Flatpak makes this experience easier 3) You've been extraordinarily lucky

I want to point you to issue #19889. This is an issue caused by AppImage requiring fuse2, which is deprecated, has many known bugs, and doesn't ship by default on modern Linux distros anymore (having been replaced w/ fuse3). The TL;DR fix to this issue is that the user had to install the "libfuse2" package, which doesn't brick Ubuntu. "fuse2" bricks Ubuntu, "libfuse2" doesn't. But this really shouldn't matter, because AppImages should not be linking against host libraries if they wish to be cross-distro compatbile. If MuseScore were not using AppImage, the user would not have to open the terminal to try and install fuse2, and would not brick their system.

Let me contrast this with Flatpak. When you develop targeting a Flatpak, you are linking against a "runtime", which is essentially its own mini-distro that is stable across versions of your app and across host distributions. In other words, with Flatpak it does not matter what distro the user is running because your app is running with a known-good set of libraries: if the distro supports Flatpak, then it can run your app. This is not something AppImage can emulate. With Flatpak, unlike AppImage, your app is being dynamically linked at runtime against exactly the same libraries that you linked against when you were developing the app. With Flatpak there is no concern about what distro the underlying system is running because none of your execution environment comes from that distro. And, all of this works with minimally invasive changes to the underlying OS (unlike Snap)

As a Mac user I like the simplicity of the App Store very much, and I imagine FlatPack and Snap on the respective Linux distros must be similarly nice.

Here, you talk about Flatpak (and Snap) as belonging to a "respective Linux distro". For snap, this is somewhat the case as mentioned above. But for Flatpak this is notably not the case, and Flatpak was designed to work on any and all distros. That is Flatpak's entire purpose: write the app, compile it once, publish it once, and it runs everywhere. This is the promise of Appimage, but successfully executed on a technical level (whereas AppImage is a bit of a half-assed solution that does not and can not work as advertised)

The only popular distro that isn't really on board w/ Flatpak is Ubuntu. Ubuntu requires Flatpak to be installed, and doesn't integrate quite so well with the app stores. But this point is moot because AppImage 1) doesn't work on modern versions of Ubuntu (22.04 and newer) without installing "libfuse2" and 2) doesn't integrate with app stores (or even the desktop environment w/o manual user action). Flatpak is no worse than AppImage here

AppImage is very convenient because you can do the work only once and still support quite a lot of Linux distros

As mentioned above, AppImage does an extremely poor job of this. I would describe any claim otherwise as uninformed or just outright deceptive. Flatpak does the same thing in a much more convenient, compatible, and overall functional manner.

Other ways of packaging/distributing are often limited to a few distros, which would mean that we need to create and maintain packages for a lot of different systems

I completely agree that you shouldn't be packaging things per-distro. Flatpak allows you to avoid this. AppImage notably does not. If you read through AppImage's guidelines on packaging apps for AppImage, you'll notice that step one is picking what distros the app will run on and that colors the whole rest of the process.

Choosing one system doesn't really work; the Muse Sounds team initially chose one popular way of packaging, but then immediately people complained that they need other ways too

Lots of Linux users have opinions that aren't really based on the facts of the technology. People, for instance, think Flatpaks are huge and bloated because each Flatpak has its own copy of its own OS (false: the runtimes and even individual files are shared between apps), or that AppImages are universal (false: they link against host libraries), or that app developers should stop being "lazy" and just package their app for every distro under the sun instead of using AppImage/Flatpak/Snap (false: this is just plain silly and entitled). My point is, people often don't know what they're talking about when it comes to packaging.

Muse Sounds always needs to be installed separately, because it can't be packaged with a GPL3-licensed program which MuseScore is

Flatpak allows for this, via a mechanism called Extensions. Basically you can package plug-ins for Flatpak apps. This way, you can ship the MuseScore Flatpak as its own app, without the sound library. Then you can package up the sound library as a proprietary Flatpak extension that gets installed separately.

This is a technique used by many Flatpak apps to deal with codecs. The app itself doesn't ship codecs, but it does download special extensions w/ codec packages in there that the app can then utilize. These extensions are their own entities, as far as Flatpak is concerned, so they can be licensed under their own license (possibly even proprietary), and uninstalled/separated from the app.

P.S. Flatpak is recieving investment and attention from the community at large, and the companies. Work is being done to make Flathub behave pretty much exactly like an "app store" on the proprietary OSs, up to and including ways to collect money/donations for your work (i.e. a "pay what you want" model for users). In my opinion, switching to Flatpak and Flathub is the only reasonable way forward for apps that want to continue flourishing on Linux: it enables distro developers such as myself to innovate in various ways that were fairly unheard-of before in the Linux space, and so expect to see more and more distros that only officially support Flatpak apps over the coming years. IIRC, @CassidyJames is someone you can talk to (or can point you to someone you can talk to) for guidance on getting your major app on the Flathub store, taking first-party ownership of your store listing, etc etc etc.

cassidyjames commented 10 months ago

Yep, I agree with @AdrianVovk's technical breakdown above, and can confirm that I'd be happy to help however I can to get MuseScore on Flathub. :)

I'll add that Flatpak and Flathub are included out of the box or as a one-click option now across most Linux distributions---and even on Ubuntu, it's no harder to enable Flatpak than AppImage.

Steam Deck even comes with Flatpak out of the box and uses the Flathub app store for its desktop mode. So distributing as a Flatpak on Flathub would mean those millions of Steam Deck users would be able to easily get and use MuseScore by switching to desktop mode, opening the app store, and searching for MuseScore just like you'd expect on any modern OS with an app store.

Peque commented 9 months ago

@cassidyjames MusesCore is actually already available through Flathub. The only issue I found was that Wayland support is disabled making it out-of-the-box unusable for me and probably many other users currently running on Wayland (I'm using Fedora, but I see Endless OS 5 also moved away from X11 much like other Linux distributions).

I asked the maintainer if that could be updated, since my experience so far after activating the Wayland socket and removing the QT_QPA_PLATFORM environment variable with Flatseal has been great. But they decided to close the issue (I am still not sure why since there was not much discussion).

While users could do like I did and manually tweak the Flatpak permissions with Flatseal, I think that is not a very user friendly experience and many Wayland users may be just ditching MuseScore after installing it from Flathub thinking it is not working (without even looking for a specific reason or a way to fix it).

Do you know if there is anything that can be done in a case like this? I am not sure whether the current maintenance is officially supported or whether it would be possible to fork it and upload a second version to Flatpak with Wayland support (I'm guessing the latter would be a messy approach).

AdrianVovk commented 9 months ago

This is why we're asking the maintainers to make Flatpak the official distribution method. The official upstream of an app, if they choose to package their app as a Flatpak and publish to Flathub, can take over the Flathub listing with their official build of the app

Peque commented 9 months ago

@AdrianVovk Yeah, for the record I opened https://github.com/musescore/MuseScore/issues/20459 to track that suggestion/feature request. :blush:

cbjeukendrup commented 9 months ago

@AdrianVovk I've read your comment above and was still planning to reply to it, but you know... life is busy :)

Your argument for FlatPak seems very convincing to me, but that doesn't say much because Linux packaging is not really my field of expertise so I can easily be convinced of anything. (I'm not the guy who does packaging, I'm just the guy who does reading and writing of long GitHub comments 😊) So therefore I asked in the MuseScore Development Discord Server what people think. In general, those people who replied didn't seem to have a strong preference for one system or the other; however, while they were not too happy about installing libfuse2 for AppImage, they also didn't feel great about having to install a huge runtime for FlatPak (but they also mentioned that the runtime can be shared between other apps that use FlatPak). Could you comment about that topic? (How much more than an AppImage does a FlatPak runtime really include?)

A big advantage of AppImages is that people can get them working on Chromebooks. Is that also possible with FlatPak?

Finally, for development, it is a requirement to be able to easily send test builds over to colleagues. With AppImage, we just upload the .AppImage file to GitHub Artifacts, and then all involved people can easily download that file and run it immediately to test it. Running arbitrarily many different builds in parallel is also possible, because each build is just a file. And we have an archive of "nightly builds"; people can download the desired nightly build anytime, which is useful when trying to find when a bug occurred for the first time. Does FlatPak support these things too? I.e. being able to send builds around as files, easily running-without-installing without the intervention of an app store, multiple versions in parallel, downloading specific non-latest versions?

(I'll reopen this issue, so that we can use this issue for the discussion about the FlatPak format, and https://github.com/musescore/MuseScore/issues/20459 for FlatHub.)

AdrianVovk commented 9 months ago

however, while they were not too happy about installing libfuse2 for AppImage, they also didn't feel great about having to install a huge runtime for FlatPak (but they also mentioned that the runtime can be shared between other apps that use FlatPak). Could you comment about that topic?

The runtimes aren't that huge, relative to your distro at least. They're a couple hundred megabytes (not giving any exact numbers because it varies depending on the runtime you pick). And again, the storage space is deduplicated among apps and even among the runtimes so it's pretty much a one-time cost.

Also a bit of insight from a distro dev: we can start removing things from distros as Flatpak takes functionality over, which will improve the storage space situation. For example, my distro (carbonOS) will be removing pretty much all built-in video codecs, since all the apps that will ever play video are actually Flatpaks nowadays. So there aren't two copies of codecs on the system anymore. Thus, the Flatpak runtime isn't taking up any more space for the codecs. Ultimately, the overlap between host OS and Flatpak runtime will shrink over time. This is my opinion, anyway.

I also think this isn't a great comparison. libfuse2 is not just an inconvenient library to install, it's also deprecated and thus unmaintained. And AppImage has no intention of switching away from it. If you go read that issue I linked where they decided not to upgrade to fuse3, the "solution" they came up with is actually a standardized runtime environment very similar to Flatpak - just without any of the sandboxing. deduplication, or security-update benefits (and which will, of course, come with the deprecated libfuse2 library until the end of time - just to highlight that this appimage runtime is unlikely to ever get security patches to critical components)

Finally, appimages kinda have their own "runtimes" glued into every appimage! Don't forget that you're still shipping loads of shared libraries in there (even if it's not all of them). These libraries are not deduplicated among the apps: not on disk, not in RAM. Flatpak deduplicates in both places.

How much more than an AppImage does a FlatPak runtime really include?

I couldn't tell you because there's no hard and fast rules as to what AppImages include. With appimage it's entirely up to the packager (i.e. you) to decide what libraries you pull from the host system ('because everyone has them anyway') and what libraries get shoved into the appimage.

Flatpak ships the entire set of shared libraries in the runtime, with some others being shipped with the Flatpak itself. The runtimes are basically collections of the most common libraries all the apps using the runtime are extremely likely to share, and if there's a library missing the app can package it for itself. I'll give you an example: the KDE runtime ships basically the KDE platform libraries (Qt, KDE styles and widgetry, etc) along with some base system libraries (libc, openssl, etc) that pretty much all KDE apps will be using. Now you can also have your favorite KDE ebook reader app that needs an epub parser library; that specialized library wouldn't be in the runtime, so it would ship with the app.

Another way to put it is that Flatpak is very similar to app image in the split of what libraries come with your app and what libraries come from the enclosing environment. It's just that the enclosing environment is a container w/ a standardized runtime in it, instead of the actual non-standardized host OS. In appimage if you don't ship the exact version of Qt you need, then you're at the mercy of the host distro: does it have Qt installed? is it a new enough version? But on Flatpak if your app doesn't ship a custom build of Qt then you know that you'll be using your runtime's build of Qt, and thus you know exactly what you're targeting

A big advantage of AppImages is that people can get them working on Chromebooks. Is that also possible with FlatPak?

Yep. It's quite easy to set up and integrates directly with the ChromeOS GUI as well (i.e. if you enable Flathub on your Chromebook and install an app, that app will appear in the ChromeOS app launcher, shelf, etc). https://flathub.org/setup/Chrome%20OS

being able to send builds around as files

Yes. Flatpak has a concept of a "bundle" where the app is packaged up into one file and sent over.

These are usually used in, for instance, CI systems. Lots of the GNOME desktop apps have a CI that run and produce a Flatpak bundle. Someone could then simply download the bundle file, install it, and then run it. You can similarly generate a bundle and then send it over discord or email or any other medium if you need someone to test a specific build of something.

easily running-without-installing without the intervention of an app store

No, you can't run a bundle without installing it first. Flatpak does lots more things than appimage does (i.e. security sandboxing, integrating with the OS, storage deduplication, direct access through a native kernel filesystem instead of FUSE, etc) so apps take a smidge of setup.

App stores don't have to be involved. You can run flatpak install ./path/to/bundle to install the app. But honestly the app stores make this pretty easy: usually you can just download the bundle, then double click to open it, then hit "install" in the window that appears, then hit "open" once the installation is done, and that's it. I find that it's a smoother workflow than even Appimage (where you need to manually make the file executable before you can run it)

It's also pretty trivial to put together a python script or something that will automatically install + run any flatpak bundle you try to open (maybe w/ a check first to make sure it's a musescore devel build flatpak or something). This way the whole installation step is seamless to you

multiple versions in parallel

It's somewhat complicated. Flatpak apps have the concept of branches, kinda like git. You can install one version of any given branch of any app at a time.

So for instance, you can have one copy of com.example.App//stable and one copy of com.example.App//beta installed. However, Flatpak will have a "default" branch that it will expose to the system and the other branches aren't directly accessible except through the command line. So if you have a stable branch and a beta branch installed in parallel, you'd have to pick one to be exposed in the GUI and the other you'd need to explicitly specify on the command line

As an alternative, you can switch up the app ID to do parallel installation. This is quite common. For instance, you can have a com.example.App and com.example.App.Nightly or com.example.App.Devel; this alternative app ID is technically it's own completely unique app, with its own settings, storage space, sandboxing, etc. Since it's a completely unique app, Flatpak happily lets you install it along side the official release build.

Here's a real-world example of how this is commonly set up: if you go to nightly.gnome.org, they have a whole Flatpak repository to host nightly builds of their apps. These apps have a unique .Devel ID, which means you can install these nightly builds of apps in parallel to the stable versions and they don't interfere with each other

downloading specific non-latest versions?

This is one of the superpowers of Flatpak. Not only does it let you do this for development, it lets you do this always. Users can at any point go through the version history of an app, pick an extract build ID, and then downgrade/upgrade/side-grade to that version if they so choose

This is very useful in many different ways. If a user reports that they have a bug, you can ask them for an exact build ID. You can then upgrade/downgrade/side-grade your installation of MuseScore to that exact same build ID and try to reproduce the bug. You can even do the same with the runtimes to get an identical execution environment as the user as well (or just ask them to make sure the runtimes are up-to-date)

You can also upgrade/downgrade/side-grade via a bundle. IIRC, Flatpak doesn't prevent this

Finally, for development, it is a requirement to be able to easily send test builds over to colleagues. With AppImage, we just upload the .AppImage file to GitHub Artifacts, and then all involved people can easily download that file and run it immediately to test it. Running arbitrarily many different builds in parallel is also possible, because each build is just a file. And we have an archive of "nightly builds"; people can download the desired nightly build anytime, which is useful when trying to find when a bug occurred for the first time.

As a bit of a summary, I'll re-iterate. This workflow is well exercised w/ Flatpak. It's pretty much exactly what GNOME does.

Each app has a CI pipeline that uploads a Flatpak bundle on each commit. This is your Github artifacts scenario.
GNOME also has a Nightly flatpak repo (nightly.gnome.org). A bit of infrastructure builds apps and publishes it to the nightly. Since you're doing this for just one app, you can have a nightly CI pipleine that just pushes the flatpak into a flatpak repo instead of uploading to github artifacts
Once the nightly repo is a thing, your users will be able to upgrade/downgrade their installation to quite literally any version in your repo or even upgrade via a bundle (generated either by you or by your CI)

cbjeukendrup commented 8 months ago

Okay, to come back to this issue: @AdrianVovk @cassidyjames, How much work would it be to set up proof-of-concept FlatPak packaging for MuseScore, in addition to the existing AppImage packaging? And to what extent would you be willing to help with this? I can imagine a situation (at least in the beginning) where we support FlatPak as an experimental system, i.e. we don't test it as thoroughly as AppImages, but we do try to fix user-reported issues whenever we can. Just like we do with PortableApps on Windows. If the FlatPak version really takes off, we might swap the roles and make FlatPak the primary supported way.

cassidyjames commented 8 months ago

I imagine the very first step would be to upstream the existing manifest and set up CI to start testing it: https://github.com/flathub/org.musescore.MuseScore

There are also some downstream patches in that repo that would be good to upstream to ensure the Flatpak matches the upstream distribution as closely as possible.

Even if it's considered experimental, it could also be worthwhile to walk through the verification step on Flathub to signal to users that it's coming from the upstream project and is not modified aside from packaging concerns.

I am more than happy to help on the Flathub/verification side and point you in the right direction for other questions!

Isaskar commented 8 months ago

AppImage is indeed not that well supported nowadays, here's the experience of a regular user (me) trying to use the AppImage build on a popular modern Linux distribution (Fedora 39)

If you then click the "Search in Software" button, you get taken to an app to manage AppImages - which happens to be a Flatpak app on Flathub.

Flatpak/Flathub would probably also make sense for the new Muse Sounds Manager, where you currently distribute a .deb and .rpm and still don't cover every distro.

MarcSabatella commented 8 months ago

@Isaskar Looks like you simply forgot to make the AppImage file executable. If you need further help getting the AppImage installed and running, please ask on the official Support forum at musescore.org

Samueru-sama commented 1 month ago

I will respond here because I notice that the intent of some of the users here is to drop the appimage for flatpak support instead of requesting flatpak support which is crazy.

is not available in system app menu does not have an icon cannot be added to favourites in the taskbar has to be manually downloaded in a browser, so you can't run an install script to install Musescore in a new system automatically with user input

You get all or almost all of this by using an appimage manager, stuff like appimagelauncher, zap, gearlever and the one I always recommend, which is AM/AppMan.

Not to mention that some devs even include said functionality into the appimage as well.

AppImage is, at its core, a complete misunderstanding (at best) of how to link libraries in a cross-distro compatible way. The claim is that that by rolling everything into an AppImage, you get to support all/most distros, because you ship all your libraries. Except that is blatantly false: AppImages still link against the system's glibc, and other libraries like libfuse2 (which is unmaintained). There is a reason for the recommendation that you build your AppImages on the absolute oldest LTS supported distro you can find anywhere: otherwise, your AppImage will link against a newer version of glibc than your consumers may have, and so you will be unable to run the AppImage on those older LTS distros. This, of course, increases your maintenance burden because you're stuck compiling your app images on ancient builds of Linux distros from years ago. I don't really know what else to say about it: AppImages do NOT bundle all the dependencies they need, and so that means that you are always going to be stuck with weird distro-specific edge case bugs due to ABI incompatibilities between distros. An AppImage's reliance on deprecated libraries like fuse2 will only become a bigger problem over time (https://github.com/AppImage/AppImageKit/issues/1120, where they decided not to port to fuse3)

You can now get appimages with the static runtime that work with fuse3.

Also appimages could always work even without fusermount by running them with the --appimage-extract-and-run flag which would decompress it on /tmp and execute it, they could always work

You can also now get appimages that bundle glibc and actually work everywhere, though that's still work in progress.

I want to point you to issue https://github.com/musescore/MuseScore/issues/19889. This is an issue caused by AppImage requiring fuse2, which is deprecated, has many known bugs, and doesn't ship by default on modern Linux distros anymore

Archlinux and forks are still using fuse2 as the default fuse.

Flatpak does the same thing in a much more convenient, compatible, and overall functional manner.

Can you have a flatpak on a flash drive and use on another computer, including the configuration files?

Can I have my flatpaks installed as if they were on path? with appimage it is a simple as renaming and dropping it on ~/.local/bin if I'm not using an appimage manager. Even snap doesn't have this problem lol.

Can I have my flatpaks use the existing dotfiles in XDG_CONFIG_HOME and XDG_DATA_HOME?

Can I easily have and test multiple different versions of a flatpak at the same time? Most notably gimp recently began making an appimage in their CI for testing due to this reason.

Can I have flatpak use my system's drivers instead of the outdated ones they ship?

Lots of Linux users have opinions that aren't really based on the facts of the technology. People, for instance, think Flatpaks are huge and bloated because each Flatpak has its own copy of its own OS (false: the runtimes and even individual files are shared between apps), or that AppImages are universal (false: they link against host libraries), or that app developers should stop being "lazy" and just package their app for every distro under the sun instead of using AppImage/Flatpak/Snap (false: this is just plain silly and entitled). My point is, people often don't know what they're talking about when it comes to packagin

The runtimes aren't that huge, relative to your distro at least. They're a couple hundred megabytes (not giving any exact numbers because it varies depending on the runtime you pick). And again, the storage space is deduplicated among apps and even among the runtimes so it's pretty much a one-time cost.

They are huge

And here is a more proper comparison with flatpak dedupchecker and everyhing:

Vs 30 AppImages + some other stuff:

Like it is not even close. In fact when I took those screenshots my entire distro wit the all those appimages was less than 5 GiB, so it is also huge relative to the distro.

cbjeukendrup commented 1 month ago

@Samueru-sama Thanks for providing that side of the story as well. It is unlikely that we will drop support for AppImage anytime soon, even if we start supporting FlatPak as well. We already have our AppImage creation pipeline in place, and there is no reason to remove it, until it really becomes unmaintainable, but I don't expect that to happen soon. So far, there is no news yet about potential FlatPak support. We're not against it, but don't have the bandwidth at the moment to do it, mainly because we have no experience with it so would have to do some investigation first.

musescore / MuseScore