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

Alex L 🕊 🇵🇸

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

Scott Williams 🐧

@alxlg @wickedsmoke @eugenialoli Yes, vscode can be configured to use containers. Have you tried it? It's messy. It's also a significant barrier when you didn't need to use a container for something before. I'm not saying you can't, but it's far from a trivial workflow change.

Karl R

@alxlg
Yes, it's an extra step that I want nothing to do with as either a user or application developer. I fear that it will be used as a native package replacement for more programs over time.

@eugenialoli

Alex L 🕊 🇵🇸

@wickedsmoke @eugenialoli

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.

Alex L 🕊 🇵🇸

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

Karl R

@alxlg
FOSS is a software commons. The idea of a "third-party" is a business thing. Linux distros have been providing major applications in the OS repository which share common libraries and this has been a boon for users.

Flatpak, I suspect, is being put forward by RedHat to make it easier for corporate vendors to support Linux. Big business doesn't care how much storage & RAM is wasted - "Just deploy my app now!"

@eugenialoli

Karl R

@alxlg @eugenialoli @vwbusguy

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.