I'm worried about Flathub packaging and reviewing
Posted by sensitiveCube@reddit | linux | View on Reddit | 39 comments
I'm a huge fan of Atomic (immutable) distros. I love the way it's more build in layers. Like your OS is basically an image, that can be pushed towards any device pretty easily, and reverting that image is pretty easy.
On the desktop I use Fedora Kinoite, and used Silveblue, Aeon and uBlue as alternatives. I'm pretty comfortable in using Flatpaks instead of installing packages, and for CLI stuff it's mostly Podman to run containers.
However their is something that makes me feel worried. A lot of packages on Flathub are community supported, instead of the actual developer(s) providing the build. This means you'll end up in the same situation as using a traditional package provided by the distro. I'm already seeing people dropping maintenance because of lack of interest, difficulties to break the sandbox when needed (IDE tools for example) and depencies that never get updated (even if the original devleoper is using different ones).
It makes me think if Flatpaks are really the answer. I love the idea of them, but I always compared them to Docker images but for usage with a GUI. But when you look more closely, they are pretty much the same as any other distro package (or worse when they break the sandbox to make it work). I know it's offers SDKs and other integration, but I'm worried Flatpak doesn't offer anything useful for developers right now?
I would really like to see some different approach, especially on Flathub. If it's not maintained by the developers, why not list the people that actually do? Why don't show any information on Flathub of the actual dep tree? Why not provide easy version control, multiple channels (like F-Droid on Android), etc.
I know an user needs to have an easy approach, but it feels way less intuitive compared to other tooling.
Yes I'm overreacting, but Flatpaks aren't apps you'll find in the Apple App Store. They are 90% unofficial at the moment, meaning the original developer doesn't give any support in most cases.
milchshakee@reddit
Because as a developer I usually have better things to do then to troubleshoot 5 different issues caused by an incredibly restrictive sandbox when I can just instead provider other packages that work fine.
The idea of sandboxed environments is more suitable for mobile platforms and the apple app store than for Linux.
BinkReddit@reddit
I couldn't disagree more. As someone who used OpenBSD before using Linux, which has security up the wazoo, every developer should be designing their programs with security in mind.
shroddy@reddit
How is that done in OpenBSD? Like if I download and run a game or program from the developers website (lets pretend for a moment that there is actually an OpenBSD version available) how would that compare to doing the same on Linux?
OneQuarterLife@reddit
Incredibly glad you don't develop a single application I use.
Unclear-Direction@reddit
You're okay with every package Fedora Atomic installs as an RPM, though?
milchshakee@reddit
I don't understand the hate? The OP asked for opinions and I gave my opinion as a developer who publishes applications in basically any package format / package repository. Except flatpak for the reason I gave.
Like this is the real experience, you build a flatpak and various things don't work anymore. That is the core issue
jaaval@reddit
I would say “security is inconvenient for me, people should just trust my apps” is a bit of a questionable take.
rangelovd@reddit
I wouldn't call this hate. Fully agree with Bazzite logo person‚ I don't want to run anything non-sandboxed. This isn't a hate‚ this is perfectly valid preference
Cold_Soft_4823@reddit
Someone wanted to hit you with a smug, fart smelling, reddit-traditional one line response. I wouldn't think much of it.
cgoldberg@reddit
I agree. Full stop.
OneQuarterLife@reddit
That's your experience, I do not have your problem.
I take issue with your core believe regarding sandboxing. You and your applications are not entitled to unsandboxed access of my computer. Full stop.
sensitiveCube@reddit (OP)
I think it's good you give me more insight on this. It's perfectly valid to have an opinion about something, and maybe you can find your way into Flatpaks later. :)
The idea of Flatpaks are well known. I think everyone agrees it's a good alternative compared to traditional packaging, especially for more app distribution. I do see more verified apps on Flathub, but I also see a lot of packages that are very slowly updated or being maintained by others. I have nothing against that at all, it just makes me wonder why adoption seems slow (and maybe it's me).
sensitiveCube@reddit (OP)
That's indeed one of the things I see when looking at the Flathub repo. As someone that did do some packing stuff in the past, it feels a lot try it, and lose interest later because of its challenges.
Don't get me wrong, I do like that's it's more restricted. On the other side it's the developer setting the permissions, not the user. Meaning it does ask for permission on basic stuff (location, mic, etc.), but in most cases portals aren't working or it's just device-all as workaround.
I think it can be suitable for desktop apps. I use MacOS for work, and it works perfectly fine.
milchshakee@reddit
Essentially, due to these challenges, if you're packaging a more complex application (A small note-taking application will probably work fine in flatpak), you need to have the developer on-board as various changes need to be made in the codebase as well to work correctly in a flatpak environment. If you are doing it as an outside packager, it's probably not going to succeed.
What I meant by the macOS comparison is that it's the same issue with apps from the app store there. You can either download .pkg or .dmg from the project website which will work without issues as it is not sandboxed or install it from the app store and be limited in some features as the macOS sandbox is similarly strict.
sensitiveCube@reddit (OP)
Isn't MacOS more developer friendly in that way? Like their permission system seems to be more restricted, but at the same time it feels more like Android (user pov).
Flatpak is making progress, but it needs the work of Wayland and DE SDKs, while Apple only targets specific versions of it's OS. So I do understand it will take time.
I still think the approach is good. I'm just worried about developers not being interested in getting it work and just leave it as it is.
milchshakee@reddit
It is more friendly, but you shouldn't really compare the platforms as Linux is community-driven and macOS is not. Also vastly different amounts of funding.
You have to differentiate between interest and feasibility. I would argue most developers would be happy to include their app in the flatpak store, so the interest is definitely there. But when it comes to feasibility, most developers (especially open source developers who are constrained on time) just realize that it is too much effort required. Also for paid developers and companies, the cost of getting it to work is too high for the added value.
MrScotchyScotch@reddit
Developers are still afraid of containers. They are complicated and another thing to learn, and devs are lazy. I see a lot more AppImages than Flatpaks.
Max-P@reddit
The value of Flatpak for developers is the predictable environment. It'll work on Arch the same as it would on the last version of Debian, because you'd get the exact same SDK anyway.
Some developers do in fact manage their Flatpak builds. It's not that much different than the distros shipping packages without the approval of the developers. If anything it's worse because it's hard to predict what kind of environment you'll get that way, and the distro may disable a bunch of features. For example Debian will disable anything too proprietary for their taste, or not good for privacy like auto update checkers.
You can ship features depending on newer versions than the distro might ship, safely, because Flatpak doesn't use system libraries. You know exactly what version of FFmpeg you'll get for video playback, instead of a trimmed down version because the codecs are still under active patents.
Unclear-Direction@reddit
This is kind of bad phrasing. It makes it sound like distros need the approval, which they do not. In fact, it's part of the reason why we're here in the first place: a license that make us able to do what we want with that software.
If those developers don't want that, then they need to pick a different license.
ExaHamza@reddit
Well, that's why we have licenses. Developers express their will (for legal purposes and otherwise) through a license.
sensitiveCube@reddit (OP)
I fully agree with your points. Compared to traditional packaging by the distro (Fedora, Debian, etc.) it's far more flexible and more options are available. You can include the latest FFMPEG build, or even include your own version. This is one of the reasons I chose Flatpaks over switching back to trimmed ones.
The thing that worries me about Flatpaks, is it's packaging. You can argue if Debian/Fedora themselves provide better builds, but they feel more secure to me. I was looking at some IDE tools on the Flathub repo for example, and it looks a lot are building wrappers to make sure it works, which does suprise me a lot.
I know all the good stuff about Flatpaks, but when you're maintainer, no one checks your actual code. It makes me wonder if bigger companies, should host their own Flatpak instance (repo) instead. Like they do with Docker containers.
archontwo@reddit
All Flatpaks have a manifest showing how and against what packages they are built including what versions.
In other words, it is reproducible.
The same cannot be said of packages across different distros.
I suggest you learn more about it.
MonetizedSandwich@reddit
You could have an aneurism in 5 minutes. So many better things to worry about. 🙃
dddurd@reddit
Didtro packages are not officially supported the the upstream either. For proprietary stuff, of course getting it from their websites is usually the only way. I'm maybe missing what you are exactly afraid of.
ashleythorne64@reddit
If you only want apps from the developers, enable the Flathub filter for only verified apps.
Because many have existing packaging formats and are too lazy to pick up a new one. Many developers also like the freedom of distributing their own packages without having to rely on third parties like Flathub to approve them.
For unverified apps, they now say "developed by" instead of "by" to better differentiate the difference between the publisher and developer. If that's not enough, then there's the verification ticks to better inform you.
That's somewhat complicated on Flathub since the rules for dependencies are more lax. An app may use runtimes, one of the common set of modules, links to external dependencies, or even just include dependencies in the archive.
It's a bit simpler for Fedora Flatpaks since those exclusively use Fedora RPMs,
Flatpak provides that ability. It's just that the GUI store you use doesn't display that ability.
Flatpak supports multiple remotes. So you can have the regular Flathub, Flathub Beta, Gnome Nightly, Fedora, Fedora Testing, etc.
Gnome Software and Discover would show all the entries in a dropdown list.
kaplanfx@reddit
A developer can maintain and distribute their own flatpaks, they don’t have to use something like flathub to host. It’s a single file and installing is as easy as using the flatpak-install command. I just don’t think people are aware of this functionality. They think flatpak IS flathub.
ashleythorne64@reddit
True, but there is one problem with that. Where do you get the runtime to run the app?
The app could use no runtime and bundle everything (bad for app size and security)
Include a runtime in their own repo (could result in conflicting versions of runtimes if multiple repos are being used)
Require the user to install Flathub (or other third party repo) to be able to use one of its runtimes (not fully independent of third party repo)
Ideally, Freedesktop should host its own flatpak repo that only contains runtimes. And then Flathub and other repos could pull its runtimes from there.
lirannl@reddit
Wouldn't a good solution be sometimes like Arch's "provides", so that an app could declare that it has a dependency of "gnome-runtime-48" or whatever, and multiple repos can provide that, and if it's already installed, flatpak picks that, otherwise it offers to select from the list?
sensitiveCube@reddit (OP)
Thanks for the clarification. I know you can filter and know much is supported. I'm actually saying the same thing, the GUI doesn't (always) display them. This is improving in newer release of Gnome Software en Discover, but I still feel Flathub itself is very limited and lacks developer features.
I dont know if lazy is correct. Why do most apps that can run in containers, start by providing them and actually use them, and most GUI apps don't? Shouldn't Flatpak be their starting point?
Business_Reindeer910@reddit
so what you're saying is you just want a full full features flathub repo client. seems like those clients you mentioned aren't trying to be that.
Somebody else will have to build it i guess.
You mostly only see developer oriented tools that require a big stack or servers provided via containers. Using the basic system tools like the coreutils that way would suck and be pointless
flatpaks aren't really good for these system oriented tools and tries to stay focused on gui tools since they need the runtime functionality more than most things.
BinkReddit@reddit
This is wrong. When your distribution updates libraries, it has to go through the entire list of packages that depend on those libraries and then update those packages. Flatpaks work around this by packaging the specific library that they're known to work with. This is a pro and a con, but when it comes to vendors that refuse to update their programs with the latest libraries, this is what we get.
OneQuarterLife@reddit
You do realize this criticism applies to every single distro package ever made, right?
sensitiveCube@reddit (OP)
I'm very happy with Flatpaks, and I know it's benefits and drawbacks.
I'm comparing Flatpaks with Docker images. Everyone can build a Docker image, so why do some developers don't do this for Flatpak?
I also feel Flathub is rather simple. It does work, and I appreciate everything and everyone, but maybe some developers are lacking resources or find it very difficult to get started?
I'm not a Linux developer, I do mostly web apps, which are different, but also are containerized nowadays in most cases.
Business_Reindeer910@reddit
the problem is that docker doesn't have the runtime functionality. it'd be terrible if there were a critical securityi update in openssl that required a newer version of gtk which required a newer version of gnome for the newer version of your actual application.
The deptree is a lot smaller for most things done with regular containers.
With flatpak runtimes you can just update the runtime and be fine
OneQuarterLife@reddit
This also applies to every distro package ever made. Why is Steam only distributed as a deb and not an rpm or otherwise? Developers make arbitrary decisions all the time. Ultimately it's up to us as the user to ask them to make better or different decisions.
Lucas_F_A@reddit
May I ask in which distros you've had this experience of packages being outdated, abandoned or otherwise?
I've experienced this in nixpkgs, but my superficial knowledge of a few Google searches when researching this topic reveals that Debian, Gentoo and Fedora have inactive maintainer and orphaned packages policies, and it seemed they were relatively complete policies.
So I thought it was just a nixpkgs issue, which does not have such a policy (or it's not checked nor enforced, at least), and the barrier to becoming the maintainer of a package is IIUC, very low.
ImNotThatPokable@reddit
I think there are a few problems with flatpak but I'm also confident that they will be fixed. I use specialized applications that don't really play nicely with flatpak.
If an application can have external plugins, that can be unworkable. I use Bitwig but I've stopped using the flatpak version because I can't install plugins into the sandbox. If you try to reference plugins from within bitwig that are not in the sandbox, they break because in the context of the sandbox there are missing deps.
ABotelho23@reddit
Go read some more. It's not very different from how packages are built and included in distributions.
sensitiveCube@reddit (OP)
That's my actual point. It feels like adoption is lacking or could be better.