@vwbusguy @wickedsmoke @eugenialoli
Here we were talking about packaging applications as RPM/DEB/etc instead of Flatpak, not about properly updating existing packages. It's a very different thing and I think it is objective that you can't have a single distro with a single graph of dependencies that include all the software out there, simply because different applications may require different versions of the same libraries. It's the whole point of containers and later of Flatpak.
@wickedsmoke @eugenialoli @vwbusguy
It's volunteer work, you can't tell people what they should or shouldn't do with their free time.
And third-party software platforms are everywhere, including browser extensions, they're not a business thing.
@vwbusguy @wickedsmoke @eugenialoli
Of course, I just wanted to say that Flatpak doesn't inherently mean more used storage and in general things need to be adapted to the new approach.
@vwbusguy @wickedsmoke @eugenialoli
Yes, I have tried, and yes, it is problematic.
Then what, we should give up and modify the OS to include packages needed for development, just because most IDEs don't integrate with containers yet?
In Windows and MacOS they don't do that and the Linux desktop approach would be crazy for them.
They are different things that doesn't make sense to compare. Flatpak is a platform for third-party applications, while package managers are a way to assemble and configure an OS or other kinds of artifacts, like container images or Flatpak runtimes.
The point is that a distro can't package all the apps out there, if you think it is possible, do your best by maintaining as much packages as you can, because no volunteer owes you anything.
@vwbusguy @wickedsmoke @eugenialoli
> The problem for IDEs in flatpak becomes when you need to access language specific compilers and libraries that you would normally just dnf install.
GNOME Builder integrates with Podman and to my knowledge VS Code can be configured to use containers too. I think this is the way: host OS ≠dev env.
> Also, having distro specific runtimes in FlarHub would be an anti-pattern for the goal of cross distribution packaging.
Indeed, I was not suggesting that.
@vwbusguy @wickedsmoke @eugenialoli
But, if in the future the host OS is deployed with OSTree and its content-addressable storage is in common with Flatpak's, a distro could hypothetically build the OSTree host images and the Flatpak apps/runtimes from the same (RPM) packages, resulting in zero duplication until the user install a third-party app from, for example, FlatHub, and even in that case only the strictly needed files would be duplicated.
Flatpak is not an alternative to RPM/DEB etc, it's an additional step in deployment, specifically for (third-party) applications, just like OSTree is the same for host OS and containers are for development environments and command line tools.
At the moment the same OSTree storage can't be shared between those three but in the future it could be, leading to potentially no increase of used storage. For more see:
@fidel @[email protected] Finally, since OSTree and Podman will support #ComposeFS we will have deduplicated storage between different containers and the host OS. And maybe even Flatpak since it already uses OSTree. If hypothetically a distro uses its packages to build images for OSTree, Flatpak and containers we would have the max deduplication, resulting in a reimplementation of a traditional distro. [...]
Mastodon (mastodon.social)
