Recent searches
Search options
I'm sorry for painting with a too-broad brush in trying to make a distinction. I don't think it's unfair to say that Flathub's requirements (which I have read) are a lower barrier than all this: https://docs.fedoraproject.org/en-US/packaging-guidelines/. The Fedora guidelines are much longer and use "must" instead of "should" a lot more times. I also think it's fair to say that developers prefer the Flathub approach. But I shouldn't have made it sound like the wild west.
Earlier in the day, I had checked with someone who should know about the privilege escalation possibility, and it turns out they were mistaken and I repeated that. I'm sorry for that, and glad to be wrong.
I obviously wasn't clear enough to on what I said about the verified check — I certainly didn't think I was saying anything different from your longer version.
Also, sometime during the whole OBS discussion, someone said that Flathub was intending to move away from the build system and have verified developers submit binaries. I should have verified that myself, but I kind of latched onto it because, were it true, it would present a natural place for cooperation. (We're working on a new, more flexible build system, so it seemed like a timely opportunity — again, were it true. Oh well.)
@mattdm @alatiera I don't think longer docs with more must equals higher barrier. it also omits the checks the linter does. So you at least need to add this page https://docs.flathub.org/docs/for-app-authors/linter and probably more.
I hadn't seen that (at least not recently!). It's very cool and I'm sure we could learn something from it. I'll make sure to mention it next time I talk publicly about this.
That said, I do think there's a basic fundamental difference. Let me try to put it neutrally....
Traditional distro packaging is concerned with integration, and with making everything consistently fit together in a way that is intended to provide user benefit. By this mechanism, we make everything better, helping keep software up to date, finding and helping fix bugs, providing user support, building for many architectures, and so on. Whenever possible, in collaboration with the upstream.
Flathub is concerned with connecting users and developers of applications in an easy way. It tends to trust the developers to do what they know is best for their software and their userbase. This includes dependencies, vendoring, vulnerability fixes, and so on. That doesn't mean there aren't checks and safeguards, but in the ideal, the project stays out of the way. This makes everything better by building a larger developer ecosystem, providing a Linux-wide application ecosystem that can be easier for both developers and end users.
Does this sound fair? (One can disagree about the actual impact and benefits, but both groups are concerned with both developers and end users and making things better for everyone.)
The traditional distro model comes heavily from an operator / sysadmin background, which is my background as well (in the distant past!).
The Fllathub approach, as I see it, comes from a more developer-centric viewpoint.
In the video conversation, I was trying to present the first perspective, having just read hundreds of comments saying that a huge part of Fedora should not exist.
I should have been more balanced, though, because I believe the traditional dev/ops dichotomy is obsolete. (Even if the term "devops" got driven into meaninglessness.)
@mattdm @alatiera boiling it down to viewpoints, might be easy, but it feels shortsighted to me. Funnily enough, we have sysadmins, that come from distro work, that are working on flathub and it feels weird, to bring it back to a cultural difference.
IMO, we will always need packagers - be that rpm or flatpak. The work isn't that different, at least for OSS apps.
But I don't think fedora flatpaks are a net positive, unfortunately.
At the end of the day, change is hard for everyone involved.
@mattdm @alatiera but there is good, that fedora flatpaks have, that as far as I can tell, flathub is in envy of. mostly cause fedora flatpaks are OCI and not OSTree. (flathub might be able to switch somewhen)
But the work fedora (presumably) did for OCI is great and we would likely be able to improve some processes, when we start using OCI.
@fluchtkapsel @mattdm @alatiera why is that? can you fill me in what the problem is?
@razze @mattdm @alatiera see here: https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/30
At work, we use salt or puppet to provision client machines with applications. But this fails with OCI flatpaks. On further investigation, it turned out that it always fails when there's no session dbus, so even ssh'ing into a colleagues laptop to quickly install a flatpak fails.
@ada_magicat @mattdm @alatiera I don't know, haven't explored that, but would have expected the OCI layering to work to some degree (which basically are detas and deduplication to me)
> I was trying to present the first perspective, having just read hundreds of comments saying that a huge part of Fedora should not exist.
Fedora Flatpaks are not a huge part of Fedora. They are a script that takes rpms and creates an OCI container that can be consumed by Flatpak.
None of us care if Fedora continues to package apps or not. I personally think it's wasted effort but if people want to do that, that's their decision.
@mattdm @razze @alatiera What could you possibly achieve with Fedora Flatpaks that you couldn't by working with Flathub and upstream instead?
That is the crux of the problem. Fedora Flatpaks compete with Flathub, but neither Fedora nor Flathub has any benefit by doing this.
We could figure out how to collaborate instead, but you have chosen to double down on competing and in the process slandered Flathub and insulted everyone working on Flatpak and Flathub.
@mattdm @alatiera "vulnerability fixes" are a small part of what flatpak packagers need to do, but the biggest part of these fixes get done automatically by the platform. Unless you specifically decided, to overwrite that.
E.g. there was a time, when python broke a feature in their newest version and kodi basically became unusable on every linux and windows, but flathub - as I could pin it.
@mattdm @razze @alatiera Apps don't need any integration work that makes them fit everything together, and that is exactly why Flatpaks exist. Besides that, Flathub definitely also helps keeping software up to date, finding and helping fix bugs and is building for many architectures. Fedora provides nothing more than Flathub provides, and that is exactly the problem.
Flathub also doesn't "trust the developers to do what they know is best for their software and their userbase". Everything undergoes vetting, in some ways even more than Fedora. The only exception are cases where app developers publish directly via their own CI, but even the result of that is being vetted.
@swick @mattdm @razze @alatiera
The vetting isn't the problem. The review is good. The problem is that existing apps don't get purged. Right now Flathub lets me install an app using the Gnome 3.28 Platform. From https://flathub.org/statistics under "Runtime Distribution", you can see that there are hundreds of apps on EOL runtimes.
Work needs to be done to hide these apps from the online store and desktop stores until they use secure runtimes and vendored dependencies.
@that_leaflet @swick @mattdm @alatiera I still think that's neat from a software conservancy POV
@that_leaflet @swick @mattdm @alatiera that would need a flatpak change