flatpak version #738
Comments
|
that would be great! |
|
Need to wait for electron-builder to add support for it |
|
it would take an extra step but this could work https://github.com/endlessm/electron-installer-flatpak |
|
Flatpak will be a great option for any Linux user to easily install Joplin. |
|
IMHO Flatpak support is a much-needed feature and has several benefits: |
|
Can you please add the support on flatpak, I am a arch linux user and it takes ages to install joplin into my computer from AUR, Linux Mint had previous version, It will be very nice to have joplin on flatpak. |
|
@teynav - I use Manjaro and the below command works for me as another solution. This will install the .appimage. So it should work just fine on Arch too.
Regarding the Flatpak support - This is dependent on electron-builder which is already shared above in the ticket. ~ Another user |
|
How about a snap package for Joplin And how about an apt repository for debian users? |
|
I would recommend against Snaps. Their backend and main repository is proprietary. |
|
While I wait for my current PR to get reviewed again, I'm messing around with trying to build a flatpak version to solve this issue. So far, what I've found is the flatpak format is barely supported for Electron and is infuriating to setup with only a small handful of node packages available. This one seems to be the most up to date and stable one available but using it following the page's instructions throws this error in my terminal:
Anyone else attempt this yet or have some insight into this? |
|
I don't have a flatpak created but I do have a debian build if anyone wants to try it out. |
|
Would that help in any way? |
|
I’d love to see more versions released to help make using Joplin on Linux better but AppImage just works for enough users that I wouldn’t put much credence into this topic ever getting really resolved. I was recently made a member of the official Joplin team, so I’m trying to get a native implementation going to solve this issue all the way, but it’ll probably be a side project without being a part of the actual project. |
|
I actually just sucesfully made a flatpak (ironically using the latest released AppImage).. I'll possibly drop this onto a github repo if anyone's interested, also I'm happy to submit+maintain an official one on flatpak.org (this would be my first one so its probably not fully standards compliant yet) EDIT: I've put this into github - https://github.com/starkers/joplin-flatpak |
|
@laurent22 I've just read the guidelines on getting a flatpak packaged up for everyone on flathub. I do need to do some small modifications but otherwise I should be able to get this published pretty quickly but I would like your permission. So two paths forward really:
|
|
@starkers, feel free to go ahead with it, you have my permission. As for the way to release it, how would that work if it's part of CI? Does it mean there will be a flatpaks being built and added to the GitHub release files? or the CI will trigger a build somewhere else and file will appear on Flathub? |
|
Just to add that AppImages are fine and dandy, except they don't integrate in any way into a desktop environment such as Gnome, which is used as default by many Linux distributions (oh, like Ubuntu, Debian or Fedora) and they need to be started manually, from a CLI, which is really not nice for regular users. AppImage should be avoided, i would argue, because of this. |
|
There's now an unofficial flatpak package for those interested. In general I only want to support one Linux format so if AppImage is not good, I don't mind switching to something else. But the few times this came up there was no good alternative to AppImage. |
|
@laurent22 flatpak is THE format I would say distributions that aren't ubuntu use most of the time. The problem is that Ubuntu is majority of the userbase. @axelsimon that's why the install script exists: https://joplinapp.org/#desktop-applications |
|
Perhaps leveraging the Open Build Service (OBS) would be a viable way. It could create packages & instructions for multiple distributions from a single source. Despite it's history it is not just for OpenSUSE. Users could download the package from there or add it as a repository and also get future updates. I use it to install & update OpenRazer for Fedora Linux. OBS can also build Flatpaks and AppImages. Examples: |
AppImages can be integrated with the desktop environment. But unfortunately it is not straight forward for unexperienced users. One has to know that tools like AppImageLauncher or appimaged exist and how to install them for the specific Linux distribution. |
@paidhi electron-builder recently gained support for building Flatpaks, but like OBS there's only support for Flatpak bundles which I think is not what most users wish for. I think that using Flatpak bundles as a distribution method is not something that should be encouraged and we need to wait for one of these two desired developments:
|
Not everyone. If updating is done silently in the background and without authorization, it's a no-go for me. What has happened to the core idea of user in control of the linux box and security? Now pretty much everyone seems to want to have (silent) automatic updates that are applied without sudo.. people don't seem to be interested about what is changing in their programs anymore. If I had to choose, a PPA would be the absolutely first choice. If I had to choose between AppImage/Flatpak/Snap, I would choose the lesser evil, AppImage. I wish that Joplin would cater to different needs and not offer just one method of installing the software. |
You can turn off updates, it's not even handled by Flatpak as there's no mechanism or service in Flatpak that updates apps automatically, this is handle by a package manager service or GUI that calls Flatpak. |
It does cater to different needs - there's a Windows build, a macOS one, and a Linux one. The problem is that Linux is quite high maintenance and requires many different builds for many different package managers and distributions. Linux represents 20% of Joplin users but it would take 80% of the time to maintain all these builds. Basically it's not developers' fault if after all this time Linux desktop is still so fragmented. I wish distros would eventually agree on a common app distribution standard but I don't know if they'll ever get there. |
Same thoughts here. I just recently moved to linux and I had a too rosy image of how the software is distributed and then I learned about AppImage/Flatpak/Snap stuff and became somewhat worried about where things are moving (the idea behind is sound, but the implementations, for now, are not pleasing me). Was really looking forward to ditch windows and how keeping software up to date there took so much time (EDIT: I'm not after automatic updates, what I mean is that finding out and installing new versions of software started to be a burden, Vs. what I thought that in linux world a user has this one update manager that checks and notifies of new versions and keeps everything up-to-date). It seems that fragmentation is a core thing in linux world.. everybody is free to do what they want and there's always lots of people that want different things. A blessing, and a curse (if I may be so bold). |
|
@Perkolator I think the situation is not so bad. In my experience, between flatpaks and apt packages you can cover 99% of the users. On Fedora, people are used to using flatpak. On Arch, someone usually goes and makes an AUR package or they use flatpak. On Ubuntu, people use apt or snap, so apt is probably the better way to go. Debian can use flatpak and Debian users are, I think, getting used to this to get shiny userspace stuff from there nowadays too. |
Much like using Snap (Ubuntu-only) fragments it even further rather than using a PPA to target all Debian-based or Flatpak for Debian and otherwise... >_> First thing I've always done is removed Snap on any distro using it. My Manjaro rigs can use the AUR, but my Mint rigs need a manual install every time. :/ As I understand it, Snap...and Flatpak...and AppImage...were all created to reduce DLL-Hell. Doesn't solve anything, just fragments further. If I could tolerate M$ I would, I'd rather take DLL-Hell over this kind of fragmentation, but I despise M$. |
|
@laurent22 Is this yours? -> https://flathub.org/apps/details/net.cozic.joplin_desktop |
|
No, but I'm aware of it and it's well maintained. |
|
Is there any plans for an officially supported version in the future? Flatpak is the new standar and would be interesting to have an official version there |
|
Would be great if there was official flatpak support, or at least a verified version on flathub. |
|
@laurent22 Would it be possible to get the Joplin app on Flathub verified as an official distribution? Flathub has already become quite popular and I believe a lot of people install Joplin that way. Even if you don't maintain the flatpak yourself, it would still provide some legitimacy to it. CC: @catsout |
|
We still suffer of missing flatpak distro. AppImage isn't a good option at all. It doesn't integrate with the system smoothly. I think after 51 comments and lot of thumbs up it's the time to listen to the community and give joplin an official flatpak distro. |
|
@mbnoimi The flatpak distribution isn't official but it has been updated to v3 now. A week to wait after a major release isn't that long, and the AppImage worked perfectly in the mean time. |
|
To give some credence to the idea, it's worth looking at some stats. According to the Joplin website, https://joplinapp.org/help/about/stats/ - The latest available updates suggest something around 25k-40k AppImage users. The issue is, it's impossible to determine duplicate downloads, and the time scale being effectively infinite makes the data difficult to compare since it's unbounded. On the other hand, the Flatpak appears to have about 15k users, measured by downloads over 2 days. https://klausenbusk.github.io/flathub-stats/#ref=net.cozic.joplin_desktop&downloadType=updates It does that despite being unofficial. If the Flatpak were made official, you could easily imagine it overtaking the AppImage in downloads entirely. Whilst I'm sure some people would demand AppImage anyway, as there'll likely also be people also demanding .deb/.rpm - Does AppImage have any actual benefits to the developers? Alternatively, how much benefit does it have to the users? Flatpak has proved itself reliable for Joplin, and overtime, AppImage increasingly less so. Whilst I can understanding only wanting one distribution officially, in 2024, is AppImage providing any advantages consider the zero sandboxing, out of date library demands (libfuse2), incomplete library bundles (AppImages make a lot of assumptions on what libraries the system already has), no package signing, inferior desktop integration, etc. Flatpak becomes both the OS and the installation format. AppImage is every existing OS hiding in sheeps clothing. IMO it makes sense to offer both, but the preference for both developer and users seems to lean strongly one way vs the other, on average. |
Cemu has had 83K downloads on their official appimage since the release of v2.5, which happened 2 weeks ago: https://tooomm.github.io/github-release-stats/?username=Cemu-project&repository=Cemu
The AppImage has more downloads than windows While they only have had 22K downloads since the last 90 days on the flatpak? That's lower than I expected: https://klausenbusk.github.io/flathub-stats/#ref=info.cemu.Cemu&interval=90&downloadType=updates EDIT: Correction, they have had 40K downloads and updates in the last 90 days.
Yes a lot, the developer decides what goes in the AppImages and is in full control of all the depencies, with flatpak you have to choose a runtime and use flatpaks infrastructure. It also makes it extremely easy for nightly releases that the user and developer can test and compare for regressions. GIMP explicitly started making an AppImage due to this reason: https://www.gimp.org/news/2024/05/28/experiments-appimage/
This has existed for 2 years already: https://github.com/mgord9518/aisap Uses the same bubblewrap sandbox that flatpak uses.
And before that the common suggestion was to use firejail which already has profiles for appimage.
The static AppImage runtime has existed for over 2 years and Cemu uses it as well. It has no libfuse2 dependency. If Joplin still has that requirement that's because electron builder hasn't updated: electron-userland/electron-builder#8686 The devs can still do it manually like here though: FreeTubeApp/FreeTube#5747
You can bundle all the libraries inside the AppImage, that's up to the developer, I like to do it because it means that the AppImage works on musl systems as well, And also if you are on a system where the appimages does not work due to that issue, you can still run the appimage thru distrobox or similar, that's how flatpak works, the only downside is that this isn't user friendly.
What made you come to this conclusion?! |
Can you though; AppImage explicitly tells people to not include glibc. If you include things like fontconfig, you'll get incompatibilities with the host font caches. If you include GTK, you get incompatibility with the host GTK themes and config. Flatpak can do all 3 of these and doesn't consider it anything special. Saying you can include every package is true in theory because nothing stops you putting in as many as you want, but putting libraries in doesn't guarantee they even work and the testing matrix is basically infinite or so restricted to be managable it begins approximating distro packages anyway. A good example is that the the AppImage wasn't sending notifications properly explicitly because it included libraries that it was better off not having
Many situations like the above over the years (mostly outside Joplin, AppImage generally makes good candidate for Electron Apps). I'm not suggesting the AppImage is dropped, but there is reason to re-evaluate the status quo when there's more people using unofficial packages than official ones. which is cheating and including the snap with the Flatpak, but honestly for Joplin there's barely much difference between the two and this is a Flatpak thread so. |
https://github.com/pkgforge-dev/mpv-AppImage Also the inkscape appimage bundles all the libs as well: https://inkscape.org/release/1.4/gnulinux/ However inkscape uses the old appimage runtime with the libfuse2 dependency, so in order for it to work on a musl distro you would need to extract the appimage, but besides that everything else is bundled in it. Go-appimage explicitly has a mode that deploys all the libraries: https://github.com/probonopd/go-appimage
That issue was because the bundled library was broken since they bundled a very old version, the issue would happen with a flatpak if I decide to use a very old runtime or similar. One good thing of bundling all the libs is that you can actually deploy on a new/rolling release distro and not deal with those issues as well
Do you have broken GTK theme with the deadbeef appimage? I don't, it also bundles glibc, all the gtk libs, etc, etc
The example you gave was the application shipping a broken library. Meanwhile with flatpak you have situations like these, where it is outside of the developers control: https://www.reddit.com/r/yuzu/comments/11307f0/glitches_on_steam_deck_flatpak_version_dont/j8o6gsa/
All I have seen is that you said a bunch of false information about appimage, and also people complaining that GNOME doesn't show appimage icons, goes without saying that the later is a GNOME problem, they are notorious for this stuff, like do I need to remind you all of the server side decorations fiasco? |
Like the fact they bundle everything? Here's my results from running DeadBeef on WSL2:
And it only takes the one to prove it's not everything, but that's ignoring the other 30 libraries not found I'm getting, such as:
And do you know why it can't find them? Cos they're not in the AppImage after extracting it and looking manually. This was supposed to be the example of works the same everywhere?
Edit: Given it's Christmas and I'm not in a fiesty mood, I'll take my leave here because this isn't about not having an AppImage. People want an official Flatpak, people aren't asking to remove what already works. Joplin has a diverse enough community that I can guarantee if only Flatpak/Snap and kin were available, you'd lose users by cutting off people with nicher requirements. |
|
I have no stake in this (besides a small preference), but it feels like this is getting very heated. Having a Flatpak doesn't take away the ability to have an AppImage. So rather than debating which is best, shouldn't the discussion be about how Joplin can have an official Flatpak? Without imposing additional load on @laurent22, so that he can keep focusing on the awesome work he's doing building Joplin ( |
|
I agree. This issue isn't the place to be discussing whether AppImage or Flatpak is better. We should be talking about making an official Flatpak release. |
|
@JGCarroll DeaDBeeF still has support for GTK2. On the AppImage only GTK3 was deployed. Also notice that it fails with TLDR: That's only a problem if you want to use GTK2, I don't know why you would want that, I would need to bundle GTK2 and I don't know that's worth the effort given that it is you know, old lol
Yes, that one and all the other appimages I linked you that bundle glibc, and also to check the broken GTK theming you were talking about? looks like that instead you got fixiated on the GTK2 errors and decided not to continue... Just tested it on void linux musl to really show that it works everywhere:
EDIT: Removed all the GTK2 plugins and hopefully now those GTK2 error messages are gone. Anyways, good luck getting the official flatpak, iirc it was already stated that the reason is because electron builder doesn't support it. The AppImage itself is missing the |
|
The package was trying to use GTK2 because the packager put GTK2 code in it, not the user on a system that doesn't have GTK2 installed. The result is if someone installs GIMP which is still GTK2, suddenly you've got users on an entirely different codebranch on that's nearly 15 years unmaintained, and the association between cause and effect is less than obvious. The app recovers and works well, so I can see why it isn't a practical issue; but have you tested your app with Gimp installed? Would you like a better example of your AppImage not being universal? It doesn't include libpulse0 or libpipewire, as a result, on WSL2, your app doesn't play audio. An audioplayer, it's main purpose. The 7 year old unmaintained snap installs and works just fine, because the underlying platform guarantees those libraries are there and doesn't just leave it to chance. If it feels like I'm ignoring some arguments it's because I think it's because you seem to disagree with the underlying value the Flatpak runtimes bring from a testing POV, which is understandable when there's no percieved issues, but all your other arguments rely upon the premise of "just add more to the AppImage it'll guarantee it works" when the results so far show that actually you've still forgotten some stuff that wouldn't have been missed if you were a Flatpak and even introduced problems by supporting more packages than you need to, ironically proving some of the advantages of Flatpak for users and developers. I'll chipper up, you've shown some really good technology there which I find cool actually, so thanks. You have also brought up a brilliant point on making a Flatpak official; Electron Builder does have limited support for Flatpaks but there's an implicit assumption here for users that the primarily goal would probably be to release a build on Flathub specifically, where it doesn't. Flathub has various policy restrictions, one of which is they basically mandate using their own CI environment and policies; one of which is currently lacking, the "no networking during builds" rule that means currently the unofficial Flatpak doesn't include the backup plugin by default. Assuming the way forward (should there be one) was to adopt the current Flatpak repo and effectively swap maintainers, I think it'd be worth sorting that out primarily. |
DeaDBeeF ships plugins in both GTK2 and GTK3 versions, and since only the GTK3 libs were bundled, the GTK2 plugins still try to find GTK2 libraries. Note that this is intended, the appimage is based of the portable build of deadbeef, where the user may or may not have GTK2 or GTK3, this is why it ships the plugins in both versions. Worst that could happen is that the GTK2 plugin loads libraries from the host and that causes the app to crash somehow, I just made sure to delete them.
And I tested sound on the voidlinux musl vm and it worked. On deadbeef you have to select the output device and plugin in the settings, but if you are sure sound isn't working on WSL then you actually found a bug.
Seems they never figured out why that bug happened, but given that it gets fixed when access to pipewire was removed hints that either the flatpak or the runtime was missing something, the bug also only manifested on certain versions of Linux Mint and Pop!_OS which just makes more likely that something was missing. The argument you made reminds me of the people that say that rust is better when there is a bug on another programming language, Nothing will protect you from logic errors and stuff like forgetting that the app I ship has a fallback to use GTK2 is just normal and only manifested as some error messages. In any case the AppImage ships everything it needs to actually run on any linux system as shown by the screenshot I shared on a musl system where it is impossible for the app to be using the host libraries. Anyways, sorry for the spam, this all started because the bunch of false information you said about appimages, if you are still certain that sound doesn't work on WSL after making sure the right output device was selected then please open an issue at the repo and I will take a deeper look. EDIT: btw I'm on a openSUSE vm since I'm testing an unrelated thing so I just downloaded the appimage and sounds works once again, and I can confirm that the GTK3 theming is being followed even though the appimage bundles its own glibc and gtk |
and others
Operating system
Application
For linux, can you create a flatpak version?
The text was updated successfully, but these errors were encountered: