I can only say that from the beginning I'm disappointed – or maybe actually sad – that instead of focusing on a way to hide/exclude non-free software from Flathub, Fedora has chosen to directly compete with Flathub.
Sorry for the above post, I overreacted a bit.
Still, from my perspective, I don't see why there's a need for a portable packaging format, and I think having one has more risks than benefits.
I'd like to hear your point of view though.
Each distro has a different vision, and different standards of what the software should be like.
It's not that you can't install a Debian package on Arch because one is .deb and the other is .pkg.tar.xz.
It's because a Debian package won't integrate well with Arch, because eg. on Debian stuff is supposed to start automatically after installation, and on Arch it's supposed NOT to start.
@Wolf480pl Besides sandboxing or all features that ostree brings, the main advantage is obvious to me: whatever I work on, user of any distribution can benefit. It does not matter if you are Void zealot, a fan of musl running Alpine or comfy OpenSUSE user – you can just take your favorite music player and use it as is; that effort has been made once, not multiplied by number of possible distributions.
@Wolf480pl I joined Arch as a trusted user in 2011 and for a long time I've been packaging mostly desktop packages. I consider it a complete waste of time in terms of benefits to actual Linux userbase.
But doesn't installing a flatpak application with bundled megabytes of libraries, including glibc, defeat the point of using Alpine and musl?
@Wolf480pl That's something you should ask Alpine users. It was just an example.
What if a developer has a vendetta against Pulse, and uses raw ALSA, and then no other applications can make sound because the sound card is locked? (This actually happened with a KDE app in Flatpak somewhere, but idr which one.). Or just the opposite, what if a developer LIKES Pulse and a distro doesn’t ship it?
@awilfox @Wolf480pl Flatpak makes number of assumptions and never expose Alsa directly (probably could be hacked around though); one of them is that sound access means letting an app to access PA socket. At this point PulseAudio can be expected to be available by default, even if some distributions don't.
@awilfox @Wolf480pl It is unrealistic to think that distributions are going to package a new fancy calculator program, but also to expect its developer to care about packaging at all. Flatpak is the middle ground.
It also allows to shift the problem from "either we ship everything or lose users" to "we can finally try to define the base we care to maintain".
With the traditional distro package approach, the developer would make the application work with 2 or 3 most popular audio APIs, and then the packager would chose by means of configure options which one is appropriate for the particular distro.
OTOH, if you hardcode PulseAudio in the flatpak standard, better audio stacks will never have an opportunity to gain traction.
We are a cute and loving international community Ｏ(≧▽≦)Ｏ !