Distribute via Flatpak #344
Comments
Supported by OpenSUSE, Arch, Solus, Ubuntu, Nix, Void, and more. What exactly is missing?
Package managers already have a method for updating the packages via both CLI and GUI 😕
What integration is lacking? It sounds like you might have had a bad experience with a single package, but that definitely doesn't make all AppImages bad! It should be ~7.33 MiB as a final size, and ~3.06 MiB compressed. AppImageKit easily adds support for updates. Additionally, it also offers support for delta updates through AppImageUpdate which no package managers can reasonably do by default. |
|
Based on the links you provided, I don’t see anything related to Ubuntu or any other Debian based distribution packaged. I also don’t see anything here of benefit to Fedora. I also don’t see anything in any docs here about any packaged version for any distribution. I’m all for native packaging, but also intimately understand the challenges that come with trying to support that. Thus the recommendation of a universal package format that has a package manager behind it along with integration into most graphical software managers in addition to the cli. Regarding AppImages, I’ve used them on both Fedora and Pop!_OS in the last month. In neither case was there any integration with the desktop icon or launcher wise and there was nothing that facilitated updates. I fully admit there may be tools add some of this, but I have yet to experience it. Personally, and I know not everyone shares this opinion, I don’t care about the download size near as much as I care about the day-to-day niceties of things getting updated along with the rest of my system. |
|
pacstall is AUR package support in Ubuntu. MPR is for Debian based distros. For Fedora since it's an unofficial package, you'll rely on an Fedora Copr. If you'd like desktop shortcuts and/or a launcher, you'll need to pick which one suits your fancy and install it independently. |
|
Those are some interesting links that I will certainly have to remember, but the heart of what I am asking for here is not a 3rd party distribution mechanism, but rather something sanctioned and supported by this project and included in its official documentation. Such things tend to remain updated by virtue of being integrated into the project's CI/CD system, remain supported over the long term, and are easily discoverable by anyone who stumbles across this project. Something like Flatpak (which I realized just now I misspelled in the issue title) does this with minimal overhead to the project and provides a nice out of the box experience for users. |
So, for what it's worth, the officially supported update method is to install from here: https://github.com/noisetorch/NoiseTorch/releases/. The readme has instructions on how to unpack this correctly. It does have a built in updater as well. In regards to Flatpak in general, there is currently a discussion over in #302. It's a little bit stale at this point but one thing to note is that there is a technical limitation for us right now with Flatpak that would result in only Pipewire being supported due to a lack of a good way to get the capabilities necessary on the binary. If this is no longer the case than an "official" Flatpak app becomes a much more feasible option. It's possible we'll look into Flatpak in earnest in the future but that would require a few changes in order to get things like a Pipewire-only mode. It's by no means something that's ruled out but there are, sadly, other more pressing matters in regards to the project right now... With that in mind, leaving this open seems like a sane course of action to make it easier for others to find this in the future. To be honest, not having to maintain our own update module would probably be nice anyways.
It's worth noting that this is really how most programs in package managers work in general. Many packages in official repositories have a not-affiliated-with-the-program maintainer. Long term, I'd like to see it become easier for people in the AUR/Copr/Nix/anything else have an easier time managing things like distro specific patches and hopefully reach a place where we can have good rapport with those packaging things! |
|
Thanks @TheDukeofErl. Not sure if this covers the limitations you are talking about, but https://9to5linux.com/flatpak-1-12-3-released-with-important-security-fixes-support-for-more-pulseaudio-configs leads me to believe that pulse and flatpak play nice together at least to some degree. |
|
Flatpak sucks! Man you should have told them to use |
Basically only Ubuntu uses snap by default, Snap is not widely adopted on other distros, and is really slow to startup and has no big advantages for desktop apps. The only real advantage Snap offers is better CLI support, which is not even important for a GUI app like NoiseTorch. Flatpak takes a lot of space AT FIRST because it needs to install many libraries, but that also gives it many advantages (like no dependency issues, good support on all distros, etc.). As for your issues installing Flatpak, these are better discussed somewhere else. |
Is your feature request related to a problem? Please describe.
As it stands today, installation cannot be done by any package manager and no method of installation that I have seen allows for discovering and easily pulling down updates.
Describe the solution you'd like
I'd like to see this distributed as a Flatpack so that any distribution can easily utilize the application and it can be updated by the cli, Gnome Software, Pop Shop, KDE Discover, and the like along with other desktop apps.
Describe alternatives you've considered
I have see mention of distribution via appimage. The lack of package management and integration into the system as a whole of that format makes it a much less desirable solution.
The text was updated successfully, but these errors were encountered: