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.
Personally, I can't stand flatpaks or #snap. #Appimage is nicer just because it's just one delete away from within the file manager and doesn't leave crumbs everywhere. But overall, I prefer #apt, and #dnf.
@eugenialoli#Flatpak is a dismal solution to the distro. fragmentation problem. Installing the flatpak of #SolveSpace brings in over 250MB of dependencies on my #Fedora system while an RPM version only requires 6MB.
Distros refused a common package format, but at least they could have had the decency to accept a common package specification for developers to use. Something like .spec and debbuild would be nice.
@wickedsmoke@eugenialoli That's because you already have the runtime installed in rpm. Once you have a flatpak runtime installed, it'll get reused for other things that use that runtime, so the hit is less the more you use flatpak, but you're still right that rpm is more disk efficient.
@gnomelibre@wickedsmoke@eugenialoli That's the promise. Unfortunately, that's still situational. The zoom flatpak is currently still writing to ~/.zoom in addition to ~/.var/app, for example.
Flatseal can be helpful here if you want to more granular control, at the risk of breaking some features.
Combining flatpak with an immutable OS is great for security and stability in general, but the OP is right about IDEs. They're hit and miss with flatpak right now.
@gnomelibre@wickedsmoke@eugenialoli It's possible to mix flatpak and toolbox to conjure up a working runtime, but it's a huge pain. I think when container-focused development got emphasized, people heard it as general dev tools. There's zero shame in installing an IDE from rpm-ostree or tarball if it's more practical than flatpak and then use distrobox etc when it's the right tool rather than trying to force a square peg into a round hole.
@gnomelibre@wickedsmoke@eugenialoli That said, I use geany from flatpak on my Kinoite box and it works for me, but I've been using it for decades now and have gotten used to tweaking the compiler options due to containers or python venvs, so it doesn't feel any more cumbersome to me. I hear vscode users complaining about this more than anyone else.
@gnomelibre@vwbusguy@wickedsmoke I usually install Linux for friends and family on old chromebooks that have 16 GB of storage. With Debian, one of the lighter ones, I get only 7 GB free after installation with XFce. I can't afford to install Flatpaks. Appimages are slightly smaller and in rare occasions that's ok. But .deb are much, much more better in this case. I just don't like the bloat of flatpaks, especially with only 50mbps internet in my area. Sorry, not a good alternative for me.
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.
@alxlg@wickedsmoke@eugenialoli That's possible, to some extent. Flatpak uses libostree under the hood and Fedora has a flatpak repository included out of box in the distro if you want to go that route. The problem for IDEs in flatpak becomes when you need to access language specific compilers and libraries that you would normally just dnf install. Also, having distro specific runtimes in FlatHub would be an anti-pattern for the goal of cross distribution packaging.
@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.
@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.
@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.
@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.
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:
@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.
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.
@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!"
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.
@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.
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.
@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.
@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.
@eugenialoli Have you tried GNOME Builder? I find it to be an order of magnitude better than anything else out there, and at least it was architected from the start to be able to handle sandboxing and containerization.
@nekohayo I just tried it, it wouldn't compile the vala window because the project name "test" was not allowed because it's used internally by the Builder... i mean, that's quite a funny situation that almost 90% of the new users will fall into... Other than that, it spit some errors about some gnome sdk not being installed, but it did compile and ran.
Add comment