snap is great but here in fedora we have flatpak...it would be nice to have flatpak too, other than rpm's...
Hey—thanks for filing this! We're not planning on providing a flatpak because Snaps achieve a similar goal but also provide a single autoupdate mechanism for all Linux distros (which is crazy nice compared to having users download it over and over every time it's updated.)
Is there a reason you can't install the snap version? The plan was actually to stop publishing .deb and .rpm releases soon.
On Nov 16 2017, at 3:54 pm, legacychimera247 notifications@github.com wrote:
>
snap is great but here in fedora we have flatpak...it would be nice to have flatpak too, other than rpm's...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (https://github.com/Foundry376/Mailspring/issues/345), or mute the thread (https://github.com/notifications/unsubscribe-auth/AA_TnBfqTfqYNZsz1hGM4_SVE84N4Gcwks5s3EywgaJpZM4QgnIY).
Snap is more Ubuntu centric than flatpak.
Additionally flatpak does support updating and installing from repositories [1].
[1] https://blogs.gnome.org/alexl/2017/02/10/maintaining-a-flatpak-repository/
Thanks for the additional info! Is the ubuntu-centric-ness of it have practical implications? (Honestly curious—most of my development expertise is on the Mac.) I've definitely heard that sentiment before and it's definitely a Canonical initiative, but it seems to work fine on my Fedora test VMs.
well flatpak is installed in fedora out of the box, while snap is not present and you have to install it yourself (and probably packages are even a little outdated). other than that snap takes more space than flatpak and as other pointed out flatpak is more of a linux solution while snap is more of an ubuntu solution (almost outdated everywhere)
@bengotow I am making a comment as an Ubuntu user, but in short I would say it isn't quite settled which way the distribution of sandboxed applications for Linux will go. As you have noted, a weakness of snaps (right now) is the theming problem: flatpak has an interesting solution in place to basically duplicate some major themes for flatpaks, but it doesn't work seamlessly. Snap size has historically been bigger, but they now support "base snaps" which mean that the actual application snap can be decently small (similar to how flatpak is doing things as I understand).
In short, a lot of this is working its way out. Historically there is a lot of "anti-Canonical" sentiment due to a CLA, etc. that mean that for many anything Canonical is not to be liked. I think it will take a while for the dust to clear regarding what way things will go so I would encourage you to not stop distributing .deb and .rpm too pre-maturely if the build process is already in place. It could be 2 years before snap / flatpak are really mature enough to be at 100% parity with .deb or .rpm in my view.
I agree to rik-shaw's point on not to disable rpm/deb, since both snaps and flatpaks are in early stages and will take awhile for adoption. And I believe you should offer flatpaks as well, its not much to maintain, just an additional json.
Is there a reason you can't install the snap version? The plan was actually to stop publishing .deb and .rpm releases soon.
@bengotow Yes, according to the distro, it is very difficult to run a Snap package outside of Ubuntu or Solus OS (Solus had to add apparmor to offer all the snap features). In addition it is always a bad idea that the software distribution framework depends on a provider that requires a CLA to contribute and an account to install software, in addition there are no official repos that maintain snapd in many distros and the community repos are usually outdated. Flatpak adoption is betten than Snap.
Currently and even in the short or medium term, Snap can't be considered a better alternative to Flatpak.
Note: If they are going to remove the *.deb and *.rpm packages they should at least add a portable alternative such as appimage, which is usually used by default in the electron framework for gnu/linux systems.
CLAs aren't used by a lot of FOSS projects but the practice seems to go beyond just Canonical. I guess it means the license is easier for the organization in charge of the maintaining the software to change, but presumably if they did (and I highly doubt they would) change the licence of their products to All Rights Reserved, the old version (like with Reddit) would still be FOSS, right? Someone could then simply fork that and keep the software FOSS.
The install docs there are outdated. If you spot outdated repos then make topics in the snapcraft forums filing the issue, the snapcraft team are very keen on keeping snapd up-to-date across all distros. Also, as of snapd 2.27 (released a few months ago), the core snap can re-exec, which means that snapd can keep itself up-to-date without new distro packages needing to be released (though idk if this works on all distros).
As for adoption... I'm not sure. Thanks to the great work of snap advocates like Martin Wimpress, snaps like Spotify, Skype, JetBrains software, and Slack are hooked into upstream CI and updated by them, automatically. Some other software like Peek and MuseScore are also distributed by upstream. Though folks like Martin have helped them to get going, they are now the maintainers of their own snaps. I think it would be correct to say that with FOSS software, Flatpak has more adoption, but it is a close-run thing. Snapd seems to be stronger with non-FOSS upstreams, Flatpak seems stronger with FOSS upstreams, but there are exceptions and, for the gaps in both, usually snappy/Flatpak advocates maintain packages. Canonical themselves maintain various packages like those for LibreOffice, Chromium, and some GNOME applications (as a distro maintainer would, but this time they're all fully up-to-date like they would be on a rolling system, but without the stability questions).
Please don't stop publishing DEBs and RPMs as they are so simple and universally useful.
I tried to install the Mailspring Snap on Fedora, but unfortunately snapd messes with SELinux - my only choice would have been to set SELinux to permissive mode (i.e. turn it off), but I just simply installed the fast and simple RPM. (This SELinux bug will hopefully be fixed by Fedora devs soon.)
I don't mind upgrading every few weeks anyway.
@gombosg please can you report that issue to https://forum.snapcraft.io/ ( and tag @zyga ), if it's not already there? The install docs for Fedora suggest that it should just work...
Also hopefully snapd will become reliable enough and usable on every distro that Debs and RPMs could be dropped (though I'm sure some people would continue to maintain Debs and RPMs independently), but I agree that at least for now Debs and RPMs should continue to be produced!
Hey, on any supported Fedora system you should be good to, just install snapd from the archive: https://docs.snapcraft.io/core/install-fedora
If there are any issues please let us know!
@legacychimera247 you can work with Fedora developers to enable it by default. If they do I'm sure it would be an interesting sign of good will but as things stand today it's a technology and politics game, not just technology.
On Fedora confinement of snaps doesn't work yet
@zyga if this is a political game too could you push Ubuntu devs to fix this bug for Flatpak with Ubuntu Software (currently marked low priority)? :)
@ziggy42 that's now been edited by the snappy lead - it's out of date information, it should just work :)
@ziggy42 confinement is complex and not a boolean flag that is on or off. Many parts of the confinement story work on Fedora (seccomp, namespaces and cgroups). It is true that apparmor is not supported on Fedora. In the future that may be fixed but this is a long process.
@Ads20000 ubuntu is maintained by a lot of people that are not on a payroll. Anyone can jump at that bug, investigate it, fix it and provide a patch. I cannot tell anyone to work on that more than you.
During my daily hacking on snapd I'm testing everything I work on on Fedora (and others). Perhaps flatpak developers could just look at making their software work on Ubuntu?
hi there and sorry for the late reply...well as flatpak is the fedora default package (other than rpm of course) i was more inclined to that than having to install snap support, that's why i was asking for a flatpak (and because flatpak helps keep pc's clean (as snap obviously) more than for the confinement...
anyway i ended up trying the rpm package, so that's not really an issue anymore... :)
@bengotow Yes, according to the distro, it is very difficult to run a Snap package outside of Ubuntu
LOL? :) I'll just leave this here:
https://forum.snapcraft.io/t/yes-snaps-are-cross-distribution/3906
I'd love to be able to install Mailspring from flathub
Please support Flatpak instead of (or in addition to) snap. I'll just leave this here:
https://kamikazow.wordpress.com/2018/06/08/adoption-of-flatpak-vs-snap-2018-edition/
In honest opinion, Flatpaks are better than Snaps. The wide adoption of Snaps comes from the wide adoption of Ubuntu only, and let's be honest Ubuntu is not as great as it used to be -- it did an amazing job back then to popularize Linux, it was the first distro I used and loved. But today it is broken and outdated.
Coming back to containers, I have been trying Snaps, Flatpaks and AppImage versions of the same applications on my Fedora whenever I could, apps such as Spotify, Zoom, Discord.
They all worked pretty much the same, except Themes do not work on Snaps. And to be fair neither on Flatpaks, but Snaps look like Windows 95 on drugs while Flatpaks will use a fallback theme, which is great. Windows 95 appearance is a huge no-go for me, so sorry guys I cannot deal with that.
Further on, Flatpaks will give you a list of permissions it needs to have access to upon installation, and ask you if it is fine - similar to how Android apps used to behave.
Something else I notice -- Flatpak applications tends to be more up-to-date than their Snap counterparts.
Some apps don't even have Snaps but they have an updated Flatpak -- even more up-to-date than their RPMFusion repos. An example is Zoom.
I would probably give reference to AppImages over Snaps or Flatpaks but I just didn't see any AppImage out there that I could try.
Would you guys be interested in a community-maintained Flatpak? I'll be happy to work on this myself, though I can't seem to find where the .deb files are hosted...
@kirbyfan64 wow, that sounds great! Especially if some automated build system could be set up. Is that possible?
The best reason to use flatpak is that it is a community project where a number of distros and companies are working together vs one company. This means that the speed of development will be a lot faster than snaps and it will have widespread support and integration in large number of distros. Consider flatpak developers are integrated with the rest of the desktop eco-system. I say this as a GNOME project person. Also, I would love to invite you to our next libre application summit - http://las.gnome.org/ was last year, but having app developers come and talk about their issues with the eco-system especially things like ubiquitous apps. Next year we should have both flatpak and snaps people there.
@sramkrishna using flatpak is fine but please don't claim that one or the other has mythical community value over the other. People using and making snaps are also a community. Make the argument technical, that's the only fair thing to do.
Flatpak is integrated with the gnome package manager and other standard DE tools. Snaps are pretty Ubuntu-centric.
@kallisti5
the gnome package manager
GNOME doesn't have a package manager (though Flatpak grew out of GNOME so Flatpak itself can almost be considered GNOME's package manager), did you mean GNOME Software (the appstore)? Both snappy and Flatpak have plugins for that - both have integration with it. What other 'standard DE tools' are you referring to? :)
"Gnome Software" is what I meant :-)
This article gives a pretty fair breakdown of each:
https://kamikazow.wordpress.com/2018/06/08/adoption-of-flatpak-vs-snap-2018-edition/#comment-1117
Flatpak is integrated with the gnome package manager and other standard DE tools. Snaps are pretty Ubuntu-centric.
Snaps are also integrated with gnome software but if you knew that you would not have posted this statement. Even if they were not this is totally irrelevant to what people use and develop. Be great to each other.
So, you're ignoring the comparison of flatpack vs snap showing a consistent lack of snap support outside of Ubuntu. Ok..
Talk is cheap. Here is a chart backed by real world data showing the status of cross-distro support:
@niemeyer thanks, out of the top 20, 1 is a non-Ubuntu/Debian derivative (Fedora 28)
@kallisti5 What about the top 50? How many of these are Debian, Ubuntu, Fedora, Arch, or OpenSUSE, or ... based? How many actual Linux users does that cover?
There's bias, and then there's blindness.
Heh. Blindness... so:
I feel like most of the data points to not trusting Canonical skunkwork projects :-)
Thanks for making my point more clear, @kallisti5. Nothing we do or say can fix irrational hate.
Have a good day everyone.
at the end of the day.. just don't discontinue rpm's / deb's if you're going to just release snaps without releasing flatpak's
also, @niemeyer + @zyga work for Canonical. They have some bias :roll_eyes:
I wish Canonical employees would announce their biases before getting involved in threads like this.
Guys guys, please... This is a request to add a Flatpak, not a giant face-off as to Snap vs Flatpak (and of course Canonical and Red Hat always get brought up)... At this point the discussion is going nowhere.
systemd and Upstart was a viable alternative, but Debian went with systemd and Ubuntu killed the startup manager fragmentation (which many accuse Ubuntu of) by killing Upstart, but there was certainly a point to it existingJust because stuff happened in the past, doesn't mean it will happen again, then again, if snappy is not scrapped, people will hate because it exists and Canonical is bad (supposedly), if snappy is scrapped, then it confirms people's beliefs that Canonical is bad. Canonical can't win!
I sometimes get involved in the snapcraft forums but other than that I'm not a Canonical employee or anything and I'm happy to back their criticisms of your arguments @kallisti5, does that help? :P I think it's great that they're keen to engage with criticism and seek to make things better. There's two particularly controversial threads on the forum that are kept open so that the team can engage with the community and make snapd better, not necessarily capitulating to criticism but learning from it. That's good, right? :)
Also, yes, the article is right, snappy is often not fully supported by the OS it runs on, or is lacking a few features (like re-exec - automatic updating without needing new snapd packages), or the package is out-of-date. Flatpak, also, is not always up-to-date on every distro (Flatpak isn't 1.0 on every distro yet) but was when that article happened to be written! However, it does run on pretty much any GNU/Linux OS and the team are very happy to help people get it working if you have problems (just jump on forum.snapcraft.io). Flatpak doesn't have this easy-dev-access in the same way, I don't think mailing lists and IRC (presumably not logged or reference-able?) are as easy for people to engage with the devs as the snapcraft forum is (they also have GitHub, Launchpad Bugs, and IRC, but things are explicitly centralised around the forum, that's the go-to place).
Snaps achieve a similar goal but also provide a single autoupdate mechanism for all Linux distros
Apart from CentOS, and many others...
(Whereas Flatpaks and AppImages would work fine!)
@triangulum CentOS support is in the works. There are some kinks with the older kernel there and with older SELinux policy. It is well on our plan to support it.
Meanwhile on Fedora Silverblue 29:

And we cannot install RPMs on OSTree systems.
@fbruetting to have Mailspring work on Silverblue please +1 (thumbs up) the following Issues and comments:
https://github.com/projectatomic/rpm-ostree/issues/1711#issuecomment-446237928
https://github.com/projectatomic/rpm-ostree/issues/337#issuecomment-307675484
I can't speak for others, as I haven't really used either much... but as a linux lay person, I've definitely heard about flatpak more than snap. And given Ubuntu's history of often dropping a position on tech in favor of the broader community, flatpak will probably win out here. You can do flatpak on ubuntu, and as of at least 18.10, it's in the main ubuntu repo (no PPA needed).
Aside, for context: I've taken a few year break without running linux as my main desktop, mostly using linux, docker, etc as a server-side app target for deployment and development. I'm probably going to go back into Linux later this year when I do a hardware refresh (first in 5+ years, on hackintosh). I also almost always use Ubuntu or CoreOS for servers.
I'd say flatpak should DEFINITELY be considered. I was actually surprised to not see it in flathub.
And we cannot install RPMs on OSTree systems.
@fbruetting - just to clarify that you can install rpms on ostree systems. I'm not here to argue with anyone about merits of package managers just wanted to chime in here on this specific point.
This is from the rpm-ostree (version 2019.3) man page (emphasis was added by me):
install
Takes one or more packages as arguments. The packages are fetched from the enabled repositories in /etc/yum.repos.d/ and are overlayed on top of a new deployment. It is also possible to specify alocal RPM package that resides on the host. Overlayed packages can later be removed with the uninstall command.
```
@msheiny
Oh of course, I think I wanted to write something different which I don’t recall anymore. Just forget this line! ;)
@fbruetting You were probably thinking of support for installing packages that use /opt, which was only added month ago.
I'll also add that we have no intention in supporting Snaps on Pop!_OS. elementary OS is also focusing solely on Flatpak. Only Ubuntu and its official flavors are guaranteed to support Snap, as its a requirement to be an official flavor. Everyone else is using Flatpak.
Both snappy and Flatpak have plugins for that - both have integration with it. What other 'standard DE tools' are you referring to? :)
... and GNOME Software is dropping Snaps.
https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Software-Dropping-Snap
Now can we get a Flatpak package for Mailspring?
Love Mailspring and with so many distros providing first class support for Flathub/Flatpak, it'll be a shame if Mailspring did not make it in there. Linux Mint (my current distro) has no plans for official snap integration and is throwing it's weight on Flatpaks. Please consider making a Flatpak! Many thanks.
Would you guys be interested in a community-maintained Flatpak? I'll be happy to work on this myself, though I can't seem to find where the .deb files are hosted...
@refi64 ... isnt' it time for mailspring to support a flatpak version ...
i speak out of experience ... I have installed and reinstalled my linux system so many times(along with multiple installation in a multiboot OS for testing purposes ... but i have installed flatpak applications only one time(on a separate partition dedicated to flatpaks) ... and i have been able to run them after each and every fresh install as well as from all my additional installations(2 more) without issues ...
i guess flatpak deserves recognition for this aspect of installing-only-once and not just distributing-only-one-version ... look forward to you reopening the flatpak-PR soon .
Cheers.
The best reason to have either snaps or flatpak is to be able to get metrics on how widely distributed mailspring is on the Linux platform.
The best reason to have either snaps or flatpak is to be able to get metrics on how widely distributed mailspring is on the Linux platform.
@sramkrishna ... its still a long way from giving metrics that are realistic and that can be truly considered ...
Currently be it snaps/flatpaks/appimages, all these technologies are being used only by a few tech savvy users of the linux world ... the metrics will be revealing and realistic is only when an average / noob linux user adopts these forms of app delivery ... And this will truly be possible only when a linux distro/flavor agnostic app-stores become the norm and accessible to average/noob linux users.
@aiamuzz Most of our users on Pop!_OS are using flatpaks. The same is true for elementary OS, as well. The elementary appcenter, used on both Pop!_OS and elementary OS, supports Flatpak. GNOME Software and KDE Discover also support Flatpak.
@aiamuzz Most of our users on Pop!_OS are using flatpaks. The same is true for elementary OS, as well. The elementary appcenter, used on both Pop!_OS and elementary OS, supports Flatpak. GNOME Software and KDE Discover also support Flatpak.
true ... the new linux distro's are working towards supporting flatpak apps in their native app stores ... even my DeepinOS team had it ... but recently they have dropped flatpak support from their app stores for lack of resources ... as they are running thin on manpower.
Still the number of linux users introduced to flatpak through these newer distros is good but not substantial enough ... its adoption will improve exponentially only if there is a single(central) flatpak exclusive app store ... say a full fledged flathub app store(not just the website which lists the commands to install(rather than a one click install) model(even snaps has been hosting a website with the command and not a one-click model) ... but i guess flatpak/flathub team too is spread thin to be able to develop and maintain a complete(with on click install/uninstall/update) and exclusive flatpak store !!!
until such time flatpak will have to spread through fragmented stores supported by individual OSe's ... another flip side of a distro maintained flatpak stores is that it may have a different way of packaging and delivering flatpak apps (at least DeepinOS had a completely different way of doing it ... nothing like how flathub serves/delivers apps) ... i don't know how elementary and pop Oses have been serving flatpak apps in their stores ... if by chance they are doing it exactly the same way flathub is doing then that will be a good thing ...
That's exactly why we have https://linuxappsummit.org/ - to organize and create a measurable market. Something I hope the mindspring folks and community members will show up for. Collaboration is the name of the game.
Pretty much all Gnome-based distros offer native flatpak support in the gnome software center.
@aiamuzz There is [bauh] as an option that is not tied to a specific application store. It supports both Snap and Flatpak. The discussion is happening on the [Manjaro forums].
That's exactly why we have https://linuxappsummit.org/ - to organize and create a measurable market. Something I hope the mindspring folks and community members will show up for. Collaboration is the name of the game.
@sramkrishna ... hey that's great ... didn't know such an initiative was on ...
Pretty much all Gnome-based distros offer native flatpak support in the gnome software center.
@kallisti5 ... i agree there is distro specific support in app stores ... Gnome, PopOS, ElementaryOS ... DeepinOS until a while back ... but that will still be a fragmented approach ... what a noob/average linux user needs is an exclusive store that will cater too these technologies(flatpak/appimage/snap) ... that will be THAT ONE BIG step in the right direction that will enable users to embrace these distro agnostic technologies irrespective of their linux expertise ... a case in point are Android Play Store & Apple App Store ... hell forget about expertise in anything ... 3-4 year kids have taken to these app stores like a fish takes to water ... in fact the click and install/update/uninstall model and the singularity of it is so effective that i know of kids who are as young as 4-5 years are so adept at installing their games playing it ... and uninstalling it when their devices are returned to their parents / elders. ... that is what is needed to improve and further the use of these app sandboxing technologies.
@aiamuzz There is bauh as an option that is not tied to a specific application store. It supports both Snap and Flatpak. The discussion is happening on the Manjaro forums.
@mmstick ... bauh is the kind of initiative that i have been referring to all this while ... if this project takes off then ... that'll turn out to be real boon for these techs to be assimilated faster and effectively ... sadly i see only one user as the contributor on this project ... i guess this needs to change ... @sramkrishna ... i guess your reference 'the Linux App Summit' should adopt this 'Bauh' project instantly and take it forward ... as it aligns with their purpose and principle perfectly !!!
@refi64 ... any possibility of reviving this ... https://github.com/flathub/flathub/pull/592
I'd also like having mailspring as flatpak package. I wish it doesn't carry the blurry fonts on regular screens that electron(chromium) "enceeds" it with, but that's just my dreams....
Hey—thanks for filing this! We're not planning on providing a flatpak because Snaps achieve a similar goal but also provide a single autoupdate mechanism for all Linux distros (which is crazy nice compared to having users download it over and over every time it's updated.) Is there a reason you can't install the snap version? The plan was actually to stop publishing .deb and .rpm releases soon.
…
On Nov 16 2017, at 3:54 pm, legacychimera247 @.*> wrote: snap is great but here in fedora we have flatpak...it would be nice to have flatpak too, other than rpm's... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (#345), or mute the thread (https://github.com/notifications/unsubscribe-auth/AA_TnBfqTfqYNZsz1hGM4_SVE84N4Gcwks5s3EywgaJpZM4QgnIY).
I'd love to see this revisited. Distros with larger userbases are starting to lean towards the Flatpak ecosystem as the universal option. Pop_OS!, Elementary, and Intel's Clear project are all backing Flatpak.
There's also a movement to see devs getting compensated for their time and effort towards Flatpaks from Elementary OS.
What is the exact status on this? Is there a specific reason for not providing flatpak support, besides the argument that snap provides the same functionality? Do the official mailspring devs have to support the flatpak, or is it possible that some third-party will handle flatpak support?
Currently I use a decent amount of flatpaks on Fedora and not a single snap app. Ignoring the pros/cons of flatpaks and snaps, I would still prefer a mailspring flatpak (With this I do not mean that the snap should be discontinued). Since if I were to use a snap, I would have another way of installing applications, besides the two methods I already have to use (rpms and flatpaks).
What is the exact status on this? Is there a specific reason for not providing flatpak support, besides the argument that snap provides the same functionality? Do the official mailspring devs have to support the flatpak, or is it possible that some third-party will handle flatpak support?
Currently I use a decent amount of flatpaks on Fedora and not a single snap app. Ignoring the pros/cons of flatpaks and snaps, I would still prefer a mailspring flatpak (With this I do not mean that the snap should be discontinued). Since if I were to use a snap, I would have another way of installing applications, besides the two methods I already have to use (rpms and flatpaks).
Since there has not been a reply yet, I thought I would tag @bengotow. Forgive me if this is not the right way to bring this issue to light.
Do the official mailspring devs have to support the flatpak, or is it possible that some third-party will handle flatpak support?
The answer I believe is that literally anyone could learn how to make a Flatpak and make a Flatpak of Mailspring so go ahead, get it onto Flathub, do the work yourself since the developer doesn't seem willing :)
I think I'm gonna cry at the state of this issue :smile:
But on a serious note, would a small crowdfund encourage Mailspring to consider this. I can understand that this may not be something that's in their pipeline and hence a crowdfund could possibly be an option? Maybe people can react to this comment to see if there would be people interested to throw in some $ at this.
@maniadevice I'd contribute to this for sure
I think I'm gonna cry at the state of this issue 😄
But on a serious note, would a small crowdfund encourage Mailspring to consider this. I can understand that this may not be something that's in their pipeline and hence a crowdfund could possibly be an option? Maybe people can react to this comment to see if there would be people interested to throw in some $ at this.
I would also support this.... Flatpak runs on Gentoo and snap doesn't without systemd and I'm not installing systemd.... So
As someone who used snaps religiously in Ubuntu until the update mechanism seriously broke my workflow, and who has contributed a fix for the snap package to this project, I would like to add to the call for a Flatpak distribution. Canonical is standing increasingly isolated in their support of snaps, and the issues with snaps and Canonical's complete control of the ecosystem are becoming more and more apparent.
The other big players seem to be coalescing around Flatpak as the portable solution, and I'll add my name to the list of willing contributors here. This project is too amazing to be constrained to snaps and distribution-specific packages.
+1 for Flatpak. Please. Running Pop!_OS which based on Ubuntu but uses Flatpak. As a regular user it just works waaaay better than snap. I mostly like not having hundreds of virtual drives for all my apps. Flatpak support would be appreciated. :)
I don't really have the time to lead this, but I'd be happy to support it if someone took this how-to and did it for Mailspring:
https://opensource.com/article/19/10/how-build-flatpak-packaging
Yes. Basically anyone can make a Mailspring Flatpak, so why hasn't someone made one yet given how passionate people are about this? No-one has the time? But perhaps Mailspring's developer doesn't either?!
No-one has the time? But perhaps Mailspring's developer doesn't either?!
I'd argue that any application which accepts usernames and passwords shouldn't be community packaged. People are generally good, but this is how you get smart compromised individuals phishing credentials.
Issue open since 2017 now we are in 2020. I mean there are already distros which don't have snap like Pop!_OS and I don't want to install snap too so flatpak would be great to use.
@kallisti5 I mean, that's kind of the whole point of open source isn't it? And keep in mind that the core of Mailspring isn't open source.
Most helpful comment
Please support Flatpak instead of (or in addition to) snap. I'll just leave this here:
https://kamikazow.wordpress.com/2018/06/08/adoption-of-flatpak-vs-snap-2018-edition/