Please use a format other than AppImage -> namely FlatPak #19722
Comments
muse-bot
added
the
feature request
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
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] |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@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. 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. |
This comment was marked as outdated.
This comment was marked as outdated.
|
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:
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)
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
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.
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.
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.
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. |
|
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. |
|
@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 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). |
|
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 |
|
@AdrianVovk Yeah, for the record I opened #20459 to track that suggestion/feature request. 😊 |
|
@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 😊) 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 (I'll reopen this issue, so that we can use this issue for the discussion about the FlatPak format, and #20459 for FlatHub.) |
cbjeukendrup
changed the title
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.
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
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
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.
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 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
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
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
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.
|
cbjeukendrup
added
the
os: linux
|
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 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! |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
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.
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.
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 You can also now get appimages that bundle glibc and actually work everywhere, though that's still work in progress.
Archlinux and forks are still using fuse2 as the default fuse.
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 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?
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. |
|
@Samueru-sama Thanks for providing that side of the story as well. |
It's about maintenance burden. If MuseScore's developers want to support both they absolutely can and I encourage them to do so. Choice isn't a bad thing for a user - and if there are users who'd rather use an appimage than a Flatpak that's fine. But, if MuseScore's developers want to pick just one packaging technology and stick to it, it really should be Flatpak. Even if offering both, Flatpak should be the preferred option.
These are third-party software, that's not built into any of the major distros. The user would have to install it before installing MuseScore.
Sure, but that's now work that the MuseScore developers have to do. Flatpak has this all built in and requires no additional effort from the MuseScore developers. Also, it's difficult to get this right. What happens if someone wants to try MuseScore, and then decides that they're not actually all that interested in composing music and uninstalls it? If MuseScore took initiative and on its own dropped a bunch of .desktop entries and icons around the home directory, you'll now have app launchers in your desktop that don't actually launch anything. This is, of course, addressed by an appimage manager tool - this is why they exist. But now we've returned to that discussion: appimage requires third-party software to be installed by the user for this to work correctly. Flatpak doesn't.
As far as I understand, this requires lots of work from the app developer's side to use. They need to essentially repackage the app to port to this new system: now list all dependencies down to the C library, and adjust their packaging tooling to support creating the new static appimages. This is tantamount to rebasing their appimage onto a different distro. Correct me if I'm wrong, and there's some easy way to port to this. As far as I can tell, nobody has done this for MuseScore yet. And doing so takes work. It's not just something you get for free just by using appimage - the app is responsible for deciding what libraries go into the appimage.
I can pretty confidently say that the overlap between people trying MuseScore and people who know this magic incantation is close to zero. Imagine someone trying MuseScore for the first time. They download the file and double click it. Nothing happens. If they weren't that interested in trying MuseScore, you've lost that user then and there. But OK, maybe they care enough to go do some research, and they figure out that they have to right click on the file, go to properties, and mark it as executable. Next, they double click it again. Again, nothing happens. I think at that point the next step is to install musescore some other way, or just completely give up using it. The next step isn't to then open a terminal app,
So, sounds to me that this is just a re-invention of static linking, but less efficient. With static linking, the linker can at least perform a dead-code removal pass and remove code that's unused by the app. With appimage, you're still dynamic linking in there, but shipping the dynamic libraries as part of the static executable file. So you've got the space drawbacks of static linking: you're not sharing the code between apps using dynamic libraries. You also get the space drawbacks of dynamic linking: you can't remove unused code from those dynamic libraries. So ultimately you get the worst of both paradigms. MuseScore doesn't use all the QT widgets. With dynamic linking, the QT library contains all the widgets (so it's bigger) BUT it's also shared by all of the binaries (so in the end dynamic linking is smaller). If MuseScore statically links QT, the linker can delete all the widgets that MuseScore doesn't use (making a smaller final binary), BUT each executable linking to QT this way has its own unique copy of QT (which means that if you have lots of QT apps you're using more space). If MuseScore were a static appimage, it would simultaneously include all of the widgets (even those it doesn't use) AND it would have its own unique copy of QT. Also, now that you're interoducing glibc into each appimage: How is that better than a Flatpak runtime? You're going to have significant overlap between each and every appimage: they'll all be sharing the same glibc, the same core low-level libraries, and so on. But unlike Flatpak these bytes won't be shared at all. Sounds like this will make appimage even less space efficient than Flatpak is - the more static appimage apps you have installed, the more space you'll be wasting.
Define "default fuse". There's a fuse2 package that some things still link to, and a fuse3 package that other things link to. There's no "defualt" that a distro can prefer. Arch installs the one that your packages need. "Default" versions make sense for things like programming language interpreters. Where the user interacts with the thing directly. But nobody interacts with fuse directly; the experience of using either version is identical, and the difference completely boils down to what library the FUSE filesystem you'd like to use is using. The "fuse" package name currently points to fuse2, but it does that for backwards compatibility reasons. Some package definitions haven't yet been updated to depend on "fuse2" specifically. They still depend on "fuse", and haven't been updated since fuse3 came out, and so "fuse" must continue meaning "fuse2" because that's what it meant before fuse3 existed.
I'm sure there is some way to do that if you really want to via Flatpak overrides, but as far as I know: no, there's no easy built-in well-supported way to do this.
Flatpak puts your app into the path, it's just named by app ID (if it doesn't do so on your distro, it's a packaging bug on the distro's part - they didn't hook this part of Flatpak up). So if you install the MuseScore flatpak, you can run it via If you want to refer to it by some short name, you can easily symlink that binary into ~/.local/bin with a custom name, or just make a shell alias. No more work than appimage.
Yes, they can. Flatpak doesn't do this by default because having all of an app's state together in one place makes it very easy to clean up after the app once it's uninstalled. It basically does the equivalent of an appimage "portable home" by default (except the home isn't portable and is stored in ~, so the app can be shared by multiple users on the system) BUT, if a user really wants their apps to use the real XDG_CONFIG_HOME and XDG_DATA_HOME, this can be done via That command just puts a config file into ~/.local/share/flatpak/overrides or /var/lib/flatpak/overrides, so if you want to manage those settings in your dotfiles you're free to do so.
Answered here. But, TL;DR: no, Flatpak doesn't currently have a good story for this. I did have an idea how to solve this, and have documented it at flatpak/flatpak#5181. It doesn't seem very hard to implement. So, maybe one day Flatpak will have a solution for this.
Yes it can. Your distro can expose the a "host" video driver for Flatpak to use (see here). Generally it's a bad idea to do this, however, because video drivers are generally dynamically linked and they're not linked against the libraries inside of the Flatpak runtime. Also, Flatpak's behavior regarding GPU drivers isn't arbitrary. Appimages will need to solve this problem too if they want to work across distros. If I have a static appimage linking against musl, I can't dynamically link against any host GPU drivers on a distro that uses Glibc. Or vice versa. So, if static appimages really do work across distros, they'll need to ship their own GPU drivers inside of the appimage too. Yeah, you've pointed out a user that's installing their very first Flatpak for the very first time. They'll need to install the bulky dependencies. Then after that they won't need to install quite so many dependencies anymore. Also, Flatpak tends to overestimate download sizes. Note the "partial"s and the less than signs. The 368 MB Locale bundle contains all languages, but Flatpak will only download languages that you use. The platform will be downloaded in its entirety, but the two GL drivers are basically identical and will this only be downloaded once. The app itself is 1.5 MB. If that user were to then go and install another GNOME app, they'd only be downloading only those 1.5 MB. Even if they install another app from another platform, they'll be downloading a lot less than the whole thing: the platforms all share many of their low-level libraries (like libc) so they won't be re-downloaded, translations, data files, etc. And there's only one set of GL drivers, vaapi drivers, etc that's used by all platforms. So in practice, the user might need to download a couple hundred MB worth of dependencies this one time, but they'll never be downloading quite that much ever again.
So you've installed 7 apps and it took up 4.79 GB of space. On my system, I have 58 different Flatpak apps, which depend on 4 different versions of the GNOME platform, 2 versions of the KDE platform, and 2 versions of the Freedektop platform. This totals to 11 GB of space used. That's 8.2 times the number of apps in only 2.3 times the space. The more apps you install, the more space efficient Flatpak gets. But yes, Flatpak is less space efficient than dynamically-linked appimages. This isn't surprising: Flatpak is doing a lot more things. It actually ships a standardized runtime for the apps to run in, unlike dynamically-linked appimages which run on the host system (with variying outcomes). Again, static appimages will need to recreate a lot of Flatpak's behaviors to work right, and will end up being less space efficient due to the lack of deduplication.
Your numbers confirm what I've said. The GNOME Platform is under 400 MB in size. Your OS, which is clearly a minimal installation of some distro and uses a window manager instead of a desktop environment, is 3.5 GB in size. Your very small OS installation is 8.75 times larger than a Flatpak runtime. My Fedora Silverblue installation's /usr directory is 5GB in size. That's 12.5 times larger than a Flatpak runtime And actually, due to overhead in ostree and backup versions of the OS and whatnot, my Silverblue installation actually takes up 10 GB of space on disk. That's 25 times the size of a Flatpak runtime. That's nearly the same size as all my installed Flatpak apps and all their dependencies. Just to prove my point further: let's add up all of the platforms I have installed (and I have a lot!), and then to give Flatpak an even worse change let's assume that Flatpak can't deduplicate anything between these runtimes. The GNOME and KDE runtimes are both under 400MB, and the Freedesktop platform is under 300MB. I have 4 different versions of the GNOME runtime, 2 different versions of Freedesktop, and 2 of KDE. That's a total of 3 GB of space. That's still less than your minimal OS installation. |
The .desktop files support the And once again this is optional, they can just clearly tell the user to use a 3rd party solution for integration.
You are asking how hard it is to switch to the static runtime? that's ezpc
The runtime will actually suggest you to run And also doesn't take away the fact that they could always work...
Ok here is flatpak with almost all* the apps that I have:
flatpak ended up using +5x more storage almost all* because I was not able to find all the apps that I have as flatpak, like lite-xl or deadbeef.
On archlinux fuse2 is still dependency of ntfs-3g and mtpfs which means any user is likely to have this already "by default" installed.
This is horrible and I still can't believe that flatpak refuses to fix this, but I guess this is too much for the same people that are ok with having a hardcode
No? where did you get this from? Also what do you mean by static appimages? if it is the static appimage runtime that has no change in behaviour, it only increases the size of the runtime from 200 KiB to ~700 KiB. If you meant statically linking what's inside the appimage, that's hard to do depending on the application, however you do not need to statically link everything to be able to have the appimage work on musl systems "to work like flatpaks", you just need to bundle the dynamic linker and all the libraries it needs, which it doesn't actually increase the size of the appimage much. To give you an example, this mpv appimage that I have used to be 18 MiB before I bundled all the libraries and the dynamic linker to make it work on alpine, that increased the size to 22 MiB. This GIMP appimage that I have is 106 MiB, it bundles all the libs and works on alpine, which for something to the scale of gimp I would say is fairly small lol. Anyways I'm done with flatpak being bloated, and I'm not the only one, this alpine linux user began doing their own appimage like alternative because they were fed up of flatpak being slow and bloated. Like on their crappy laptop the chromium flatpak took 47 seconds to startup, while their alternative which is very similar to appimage takes 21 seconds.
Doesn't take away the fact that it will use many many times more storage than appimages, I don't know about you, but to me that makes it huge lol. Anyways I'm done spamming this issue, if you want to argue the merits of flatpak more you can open an issue at any of my repos. |
|
Using the static AppImage runtime is indeed easy (https://github.com/musescore/MuseScore/pull/18785/files), but we can't do it because #18830. About maintenance burden: actually, creating an AppImage is not that difficult. You just build in the normal way (as in, same way you would build locally): invoke Line 185 in 5ffd192 For FlatPak, it looks like you have to build it using completely custom tools, that wrap CMake, and don't resemble anything else so our CI scripts won't be helpful anymore for people trying to package MuseScore for their own distro; and you need to figure out how to use the correct runtime so that you don't pull in more than necessary but still profit from sharing things between apps; and passing things like secrets to CMake on the command line is seemingly no option because you don't get to invoke CMake manually; and it looks like you'll effectively have to install Qt twice, namely once directly on the CI machine because of |
Uh oh, I strongly suggest that you reconsider that, unfortunately appimagelauncher hasn't had a stable release in years, and other projects decided to prioritize the libfuse2 issue like Cemu which switched 2 years ago to the static runtime (which I didn't have anything to do there just in case unlike Zen browser lol). |
Ah, sorry for the confusion. I conflated an appimage with a "static runtime" (which just lets appimage itself run without a dependency on the system's fuse) and an appimage that bundles the dynamic linker, libc, and all dependencies.
Doesn't really help to print this on the command-line if the user is launching the app graphically, but sure point taken
Those numbers surprise me - they're quite small. GIMP isn't exactly a very dependency-heavy app, and the appimage isn't including things like GL drivers (which you can get away with because gtk2 and gtk3 are software-rendered only), but still surprisingly small here. Maybe the Flatpak runtimes are just a bit too eager with their standard collection of libraries, and can be shrunk down by removing libraries/binaries that apps aren't actually using in practice? Would be nice to collect some concrete data about this somehow and see what we can remove to cut down on the size of Flatpak runtimes.
Agreed. Casper says that MuseScore is open to supporting both so there's no reason to argue over the merits of the technologies
Flatpak's build tools may seem bespoke but they're actually closely modeled after distro package build systems, and designed to make packaging up an app easier. flatpak-builder is an all-in-one tool to fetch all your sources, then build them inside of the Flatpak SDK container (so you link against all the right libraries), then package up the resulting files into a Flatpak package. These are the exact steps any distro's build system would take to package your app. However, note that you don't actually have to use the flatpak-builder tool. Flatpak accepts packages generated using other ways. You can absolutely run cmake yourself, generate a bunch of executables and libraries, and then manually arrange them into the expected package structure and create a Flatpak package from there. In some ways this is a more challenging and manual process: you'll need to ensure that you're building your app to link against the right SDK. But, assuming you can do that, yeah you can build the app however you want and then assumble a package out of it. The other challenge is that this approach is poorly documented (but here's a YouTube video about it) flatpak-builder is just a wrapper tool around building your app and then packaging it. It just has some convenience benefits:
I would recommend using the org.kde.Platform runtime. It's basically the Freedesktop runtime (which is the minimal base image everyone builds off of), with a complete Qt distribution, and a couple small KDE platform libraries on top. Your alternative option is starting with the barebones Freedesktop runtime, then compiling your own Qt distribution on top of that. But that doesn't seem like a good use of time considering that most people will probably have the KDE platform on their system and if you build your own Qt you'll end up duplicating it instead of sharing with other apps. See also: https://docs.flatpak.org/en/latest/qt.html There's also the existing MuseScore Flatpak package definition, which is a good starting-off point: https://github.com/flathub/org.musescore.MuseScore/blob/master/org.musescore.MuseScore.yaml
There are two ways you can pass secrets into a flatpak-builder build:
Of course, if you're not using flatpak-builder then you can manually invoke cmake and pass in secrets however you want. What I'm unsure about is how you'd deliver the secrets to the CI server in the first place. I suspect you wouldn't be able to do so if you're building on Flathub's infrastructure. But you may be granted early access to Flathub's direct publishing mechanism, which will allow you to build MuseScore on your own infrastructure and then push it to Flathub for distribution. I think you'll also need this if you decide to go the non-flatpak-builder route, since Flathub's build infrastructure relies on flatpak-builder. @cassidyjames would know more.
Yeah, looks like you have a dedicated CI job to run lupdate/lrelease occasionally and then open a PR for that. You'll probably need Qt in the CI image for that job, but you've already got Qt there. For the application build, if you choose to use the KDE platform you'll be building against an SDK that has Qt included for you. So you don't need to do anything else.
Happy to answer any questions you may have, to make it a bit less intimidating :) |
|
I agree that a flatpak version would be much appreciated from a user's point of view, since this is becoming the de facto standard for packaging well-known apps on Linux. For instance, the now official way of installing Discord is through flatpak. |
|
@AdrianVovk Thanks. I think we'll just need to take a deep dive into this. We will probably not have time to do that anytime soon yet, but eventually we'll get to it. |
|
Please let the developers of your favorite desktop environment know if you would like to see better desktop integration with AppImage. In the meantime, you can use one of the tools from Please let me know if there are any other concerns regarding the AppImage format. Thanks! |
Your idea
AppImage is awful. In Ubuntu/Gnome/Debian the application:
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
The text was updated successfully, but these errors were encountered: