I love Flatpaks, the programs are nicely separated so they don’t interfere with each other. They also don’t have flaws like Snap’s low performance or Nix’s complexity.
But being limited to only graphical apps seems like a real drawback. If one wants to use Flatpaks as their primary package manager there have to be some awkward workarounds for cli programs.
E.g., the prime Flatpak experiene is supposed to be on immutable distros like Silverblue. But to install regular cli programs you are expected to spin up a distrobox (or toolbox) and install those programs there.
Having one arch distrobox where I get my cli programs from will not work, as the package entropy over time will get me the very dependency issues that Flatpak wants to solve.
So what is the solution here? Have multiple distroboxes and install packages in those in alternation and hope the boxes don’t break? Use Nix alongside Flatpak? Use Snaps?
Hmm… this is a little bit of a misunderstanding.
Flatpak is not just for graphical apps. As others have mentioned, you can run non-graphical apps from the CLI via the
flatpak run ...command and even create aliases to avoid typing all of it out.The misunderstanding is that Flatpak has a hard requirement that a “graphical” or Desktop environment must be installed (snap does not). In other words, Flatpak is not currently suitable for a headless server environment whereas snaps are. This is something the RH devs have acknowledged as being something they want to focus on in the future once the industry chooses a standard: Flatpak, Snap, AppImage, etc
The point is that you can not find most cli programs on Flathub, de facto making Flatpaks unsuitable for cli programs. Snapcraft on the other hand hosts neofetch, dust, youtube-dl etc.
not really; The lack of finding CLI programs on Flathub is more of an indication that the developers of CLI / TUI programs don’t think it is beneficial to adopt Flatpak at this time for whatever reason.
Keep in mind that among several things, Flatpak is meant to put the labor of package maintenance back into the hands of the software developers. For 30+ years the distro devs have been maintaining packages / farming it out to community members, and while it isn’t unheard of or wrong for a community member to create a Flatpak for software they didn’t have a hand in coding, it isn’t really the ideal situation either.
This is where the Flathub community will need to grow on their own. If they see that users want more CLI / TUI programs, they will need to take their own initiative and create the Flatpaks… but again, this isn’t ideal… the actual devs should do it, but not all devs can or will. Essentially, you’re talking about growing a new walled app garden infrastructure and hiring people to bring more apps into the fold and maintain them for security as well. Its not simple… and one of several reasons I personal don’t like Flatpaks
Also keep in mind that certain software likely won’t ever be a Flatpak, like GCC etc, because it may be too close to the low level distro components and the distro devs will likely want it to remain non-Flatpak for their ease of updating the distro.
I’d agree with you
If I could actually find cli app in there
There is a neovim flatpak, which is not a CLI app but a TUI one, but I guess this counts.
And there is also jellyfin-server
See my post below…
Worth mentioning that one can use bubblewrap directly over chroot to get similar behaviour as well.
It’s often simpler to use distrobox but being able to rsync chroot a between devices can be very convenient.