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...
-
@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.
-
Scott Williams 🐧replied to Karl R on last edited by [email protected]
@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.
-
@vwbusguy @wickedsmoke @eugenialoli
Flatpak is much more than just a universal package. It offers much better security (on a radically different level).
When you uninstall a Flatpak, you don't leave behind all that junk (configuration files, cache files, etc.)
And many other good things
-
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:
Alex L 🕊 🇵🇸 (@[email protected])
@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)
-
Alex L 🕊 🇵🇸replied to Scott Williams 🐧 on last edited by
@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.
-
@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.
-
@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.
-
Scott Williams 🐧replied to Scott Williams 🐧 on last edited by
@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.
-
Scott Williams 🐧replied to Scott Williams 🐧 on last edited by
@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.
-
Scott Williams 🐧replied to Alex L 🕊 🇵🇸 on last edited by [email protected]
@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.
-
Scott Williams 🐧replied to Eugenia L on last edited by [email protected]
@eugenialoli @gnomelibre @wickedsmoke Yeah, with only 16G of storage, that totally makes sense. Flatpak definitely has a bigger upfront storage cost.
I would personally use rpm-ostree in that case (w/Fedora ostree). Deb totally makes sense for Debian.
-
Alex L 🕊 🇵🇸replied to Scott Williams 🐧 on last edited by
@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.
-
Scott Williams 🐧replied to Alex L 🕊 🇵🇸 on last edited by
@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
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.
-
Alex L 🕊 🇵🇸replied to Scott Williams 🐧 on last edited by
@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.
-
@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.
-
Scott Williams 🐧replied to Scott Williams 🐧 on last edited by
@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 🕊 🇵🇸replied to Scott Williams 🐧 on last edited by
@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.