I don't understand what is the point of releasing an IDE via #flatpak, when that flatpak doesn't include all the necessary dev tools, and it can't access the ones outside its sandboxing. Honestly. What's the point? I'm looking at you, #Geany. Personall...

Karl R

IMO application developers and distro maintainers should be working more closely on packaging. A number of times I've had to poke Fedora to update packages which were years out of date. Upstream had fixed serious issues, but there seems to be no communication with maintainers.

Having a single package specification to be used on distro-specific services like Copr could help developers to do their own packaging.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli Again, I'm not saying you can't, but this is an area with a lot of opportunity for improvement in the experience of using flatpak. There are some things that reasonably should work out of box that don't currently. Another example is integrating KeePassXC to a browser when they're installed from flatpak. That's something that doesn't currently work out of box that should.

Alex L 🕊 🇵🇸

@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.

Alex L 🕊 🇵🇸

@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.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli Users can and should do whatever they want to make their system work for them the way they like it. If someone wants to use rpm-ostree, they should use rpm-ostree. It's their system.

People who care about making flatpak better should pitch in to help make it better.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli It does initially mean more storage, because there is duplication of things that are already installed on the host when you install the necessary flatpak runtime. That hit is less the more you use flatpak since runtimes get re-used, but it definitely has an initial higher storage cost.

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli As a Fedora package maintainer, someone poking us to update something is often a useful contribution to the process (when done respectfully). Because we're volunteers, it's easy for things to slip off our radar and knowing that an update would benefit someone in the community helps prioritize the work.

Alex L 🕊 🇵🇸

@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.

Karl R

@alxlg @vwbusguy @eugenialoli
Containers & bring-your-own-dependencies may have some use cases, but that should not be for normal Linux apps. One containerized program I used last year required a full 4GB, as it only ran on Ubuntu.

So yes, I'm talking about making native packaging easier for devs. I'm also looking for a healthy collaborative culture where code is updated as needed rather just punting and allowing old code to rot in an isolated container.

Scott Williams 🐧

@wickedsmoke @alxlg @eugenialoli That's less of an issue for flatpak since the shared runtimes get updated, but it's very much an issue for toolbox and distrobox environments. There's not currently a great way to keep them all updated or upgrade them if you use them longterm.