didn’t read the article, but i never got the point of having a distro-specific flathub repo. isn’t being distro-agnostic the main thing about flatpaks?
It’s about making sure you know what is inside the flatpaks. If you make your own set of flatpaks, you can distribute them with the OS. It’s not that fedora flatpaks aren’t distro-agnostic, you can use them on any distro. They just want a set where they can verify the build process and trust.
I think, because of Fedoras atomic desktops. I didn’t use any of them yet, but it seems like Flatpaks should be used there, since one should (or can?) not install tradional packages there. Therefore Fedora provides the flatpaks anyway and they can be used on the non atomic desktops as well.
Another reason is, that you might not be able to install the latest version of an application as rpm package if a required dependency in the repo is outdated. A Flatpak usually does not have the issue since a newer version would include the fitting runtime.
This said, I do think its not this big of an issue for fedora which is usually quite up to date. But if you run a distribution with LTS releases or something like Debian you will much more likely have older dependencies in your repositiry.
i guess it makes sense in that case, but i’m really not convinced flatpaks should be used as the default (or only, apparently) way to install every application in the system. flatpak’s flexibility is great for the particular cases where you want to install newer versions of applications or if an application isn’t available in the official repos somehow. besides that, just use distro packages
Another reason is, that you might not be able to install the latest version of an application as rpm package if a required dependency in the repo is outdated
Indeed. I believe most users will just switch to flathub. Sort of how most users will install some codecs, but it can’t legally be included in the base install.
Depends what you mean by “problem”. The biggest problem with traditional packages like debs and rpms is that compatibility sucks. They only reliably run on the distro and version they are designed for. Third party packages typically build on old dependencies and hope that backwards compatibility will allow them to run without issue on later distro versions.
Yes, it’s redundant to have have the same app packaged as flatpaks. Though I don’t think that redundancy is necessarily a bad thing. Flathub is not a profitable project and has up to this point relied on Gnome for funding. There’s work being done to spin it out to be it’s own thing and hopefully be supported by paid apps. But what if that fails and it shuts down? Or less dramatically, what if Flathub has a major outage?
One of the common complaints against snap is that there is only one store, controlled by Canonical. Flatpak is designed to support multiple stores. I don’t see why they can’t exist side by side. That’s exactly what I do. I have dozens of apps installed from each source.
And to address the claim of what if “each distro decides to make a flatpak repo according to their own philosophies?”. I guess that would depend on how many resources are being poured into supporting that. If flatpak continues to push for OCI support, then that would make it easier for distros to have their own remotes, if they desire. If not, they can just use an existing option. Whether that be Flathub or Fedora. Personally, I think Fedora Flatpaks are a good match for Debian and OpenSUSE’s policies, only real downside is that major Gnome app updates would be a month delayed, annoying Tumbleweed users.
i don’t have an issue with multiple flatpak repos. i’d actually find it very interesting if we went a more decentralized route with flatpak (maybe kde, gnome, mozzila would each have their own repos). but i don’t see the point of a distro-specific flatpak when we already have normal packages. compatibility is kind of a non-issue, since you’re not supposed to install them elsewhere anyway (unlike flatpaks)
also, i see absolutely no reason to use fedora’s flatpak repo on debian given that flathub exists already. you could add it if you want it, but what’s the point?
Fedora and Debian have similar philosophies. FOSS only, packages must be built from source, no vendored dependencies. So they have similar policies regarding security and Fedora Flatpaks align closer to that than Flathub.
I believe Debian also doesn’t ship patented codecs in their main repo.
that makes a little more sense, though debian is not as strict as fedora about propietary software (it is in the separate nonfree section, but that’s it)
I don’t think nonfree is enabled by default. Though I guess the repos are still hosted by debian, unlike RPMFusion. Though Fedora does treat it as semi-official given that parts of it can be enabled during first setup.
didn’t read the article, but i never got the point of having a distro-specific flathub repo. isn’t being distro-agnostic the main thing about flatpaks?
It’s about making sure you know what is inside the flatpaks. If you make your own set of flatpaks, you can distribute them with the OS. It’s not that fedora flatpaks aren’t distro-agnostic, you can use them on any distro. They just want a set where they can verify the build process and trust.
then why not just use regular packages?
I think, because of Fedoras atomic desktops. I didn’t use any of them yet, but it seems like Flatpaks should be used there, since one should (or can?) not install tradional packages there. Therefore Fedora provides the flatpaks anyway and they can be used on the non atomic desktops as well.
Another reason is, that you might not be able to install the latest version of an application as rpm package if a required dependency in the repo is outdated. A Flatpak usually does not have the issue since a newer version would include the fitting runtime. This said, I do think its not this big of an issue for fedora which is usually quite up to date. But if you run a distribution with LTS releases or something like Debian you will much more likely have older dependencies in your repositiry.
i guess it makes sense in that case, but i’m really not convinced flatpaks should be used as the default (or only, apparently) way to install every application in the system. flatpak’s flexibility is great for the particular cases where you want to install newer versions of applications or if an application isn’t available in the official repos somehow. besides that, just use distro packages
doesn’t flathub solve that already?
Indeed. I believe most users will just switch to flathub. Sort of how most users will install some codecs, but it can’t legally be included in the base install.
Not distro specific. They are Flatpaks built according to Fedora’s philosophy. But you can use them anywhere. I’ve used them on Ubuntu and OpenSUSE.
sounds weird to me. aren’t we replicating the repository problem if each distro decides to make a flatpak repo according to their own philosophies?
Depends what you mean by “problem”. The biggest problem with traditional packages like debs and rpms is that compatibility sucks. They only reliably run on the distro and version they are designed for. Third party packages typically build on old dependencies and hope that backwards compatibility will allow them to run without issue on later distro versions.
Yes, it’s redundant to have have the same app packaged as flatpaks. Though I don’t think that redundancy is necessarily a bad thing. Flathub is not a profitable project and has up to this point relied on Gnome for funding. There’s work being done to spin it out to be it’s own thing and hopefully be supported by paid apps. But what if that fails and it shuts down? Or less dramatically, what if Flathub has a major outage?
One of the common complaints against snap is that there is only one store, controlled by Canonical. Flatpak is designed to support multiple stores. I don’t see why they can’t exist side by side. That’s exactly what I do. I have dozens of apps installed from each source.
And to address the claim of what if “each distro decides to make a flatpak repo according to their own philosophies?”. I guess that would depend on how many resources are being poured into supporting that. If flatpak continues to push for OCI support, then that would make it easier for distros to have their own remotes, if they desire. If not, they can just use an existing option. Whether that be Flathub or Fedora. Personally, I think Fedora Flatpaks are a good match for Debian and OpenSUSE’s policies, only real downside is that major Gnome app updates would be a month delayed, annoying Tumbleweed users.
i don’t have an issue with multiple flatpak repos. i’d actually find it very interesting if we went a more decentralized route with flatpak (maybe kde, gnome, mozzila would each have their own repos). but i don’t see the point of a distro-specific flatpak when we already have normal packages. compatibility is kind of a non-issue, since you’re not supposed to install them elsewhere anyway (unlike flatpaks)
also, i see absolutely no reason to use fedora’s flatpak repo on debian given that flathub exists already. you could add it if you want it, but what’s the point?
Fedora and Debian have similar philosophies. FOSS only, packages must be built from source, no vendored dependencies. So they have similar policies regarding security and Fedora Flatpaks align closer to that than Flathub.
I believe Debian also doesn’t ship patented codecs in their main repo.
that makes a little more sense, though debian is not as strict as fedora about propietary software (it is in the separate
nonfreesection, but that’s it)I don’t think nonfree is enabled by default. Though I guess the repos are still hosted by debian, unlike RPMFusion. Though Fedora does treat it as semi-official given that parts of it can be enabled during first setup.
Yes, we are. It’s exactly why it shouldn’t be done and why Fedora is the only project wasting their time with this.