-
Notifications
You must be signed in to change notification settings - Fork 915
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux distribution as a flatpak #345
Comments
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).
|
Snap is more Ubuntu centric than flatpak. [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. |
@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 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 |
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... :) |
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. 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? |
@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. |
@sramkrishna ... hey that's great ... didn't know such an initiative was on ...
@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.
@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 ... flathub/flathub#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.... |
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). |
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. |
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 😄 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 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?! |
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. |
This issue has been mentioned on Mailspring Community. There might be relevant details there: https://community.getmailspring.com/t/flatpak-distribution-on-linux/68/1 |
Hey all, We are once again seriously considering Flatpak, especially as the packaging front becomes more stable. I may be helping with this in the near future. We are in the process of migrating issues to Discourse, which can better facilitate discussion and discovery, and so GitHub Issues can focus on issues that are confirmed and slated for resolution in the near term. Learn more about the changes here. As part of this, we've migrated this issue to Discourse: https://community.getmailspring.com/t/flatpak-distribution-on-linux/68 Please consider joining that community and continuing the discussion there! We're closing and locking the issue here as part of this migration. Rest assured, this doesn't mean the issue is being discarded or ignored. We hope to see you on Discourse soon! -The Mailspring Team |
snap is great but here in fedora we have flatpak...it would be nice to have flatpak too, other than rpm's...
The text was updated successfully, but these errors were encountered: