I’m in the camp of thinking Flatpaks are definitely the future for GUI applications. While there are definitely cons…
CLI applications are not feasible as Flatpaks. This isn’t what Flatpak is designed for, standard package management will still be needed here.
Dependency duplication wastes storage space, but I’m personally willing to give up a couple GBs for the benefits I get.
Developers might package their application incorrectly. This is possible, but it hasn’t caused any notable issues for me in the 2 years that I’ve been primarily using Flatpaks.
As far as I’m aware, Flatpak doesn’t have a way to allow applications to set udev rules. This generally doesn’t matter, but for something like Steam Input, you will need to install the steam-devices package or setup udev rules manually so it can manage your controllers. Google’s Android Flash Tool also doesn’t work out of the box in the Chrome Flatpak last I checked.
…The pros more than outweigh these (in my opinion at least).
Non-distro-specific packaging means you can use Flatpaks on whatever distro you want. You can have more up-to-date applications on stable distros like Debian, or on smaller distros that don’t have the resources to package every application possible. Rather than Red Hat spending a significant amount of time packaging LibreOffice for RHEL/Fedora, they can just rely on the Flatpak and spend time on more important elements of the distro itself. There’s also Bottles, which enters dependency hell if packaged incorrectly, they had a blog post about this a while ago.
Application files are stored in one place in ~/.var/app. For some apps this doesn’t matter, but it keeps applications like Steam from cluttering up your home directory with random game saves and other garbage. This also makes backups easier since you already know where all applications keep their files.
It makes immutable distros actually usable, which I believe will be the future for some use cases.
Permissions management. Even if no one is setting privileges for their applications correctly right now, having the groundwork for this in place will be important if more proprietary applications are going to be ported to Linux in the future.
Having to prefix commands with “flatpak run org.whoever.whatever…” gets old quickly, and setting aliases to get around it isn’t user friendly. It’s certainly possible, it’s just not practical (which may have been a better word to use than “feasable” in my first comment).
Let’s paraphrase to “CLI applications are quite cumbersome to use under Flatpak as per the current implementation”.
Unless you set up your own aliases, you’ll have to write out commands like flatpak run ..., and if you don’t know the package name yet you’ll need to run flatpak list --app first as well
I hope that in the future, Flatpak gets some improvements for exporting CLI utilities into the user’s environment.
I’m in the camp of thinking Flatpaks are definitely the future for GUI applications. While there are definitely cons…
CLI applications are not feasible as Flatpaks. This isn’t what Flatpak is designed for, standard package management will still be needed here.
Dependency duplication wastes storage space, but I’m personally willing to give up a couple GBs for the benefits I get.
Developers might package their application incorrectly. This is possible, but it hasn’t caused any notable issues for me in the 2 years that I’ve been primarily using Flatpaks.
As far as I’m aware, Flatpak doesn’t have a way to allow applications to set udev rules. This generally doesn’t matter, but for something like Steam Input, you will need to install the steam-devices package or setup udev rules manually so it can manage your controllers. Google’s Android Flash Tool also doesn’t work out of the box in the Chrome Flatpak last I checked.
…The pros more than outweigh these (in my opinion at least).
Non-distro-specific packaging means you can use Flatpaks on whatever distro you want. You can have more up-to-date applications on stable distros like Debian, or on smaller distros that don’t have the resources to package every application possible. Rather than Red Hat spending a significant amount of time packaging LibreOffice for RHEL/Fedora, they can just rely on the Flatpak and spend time on more important elements of the distro itself. There’s also Bottles, which enters dependency hell if packaged incorrectly, they had a blog post about this a while ago.
Application files are stored in one place in ~/.var/app. For some apps this doesn’t matter, but it keeps applications like Steam from cluttering up your home directory with random game saves and other garbage. This also makes backups easier since you already know where all applications keep their files.
It makes immutable distros actually usable, which I believe will be the future for some use cases.
Permissions management. Even if no one is setting privileges for their applications correctly right now, having the groundwork for this in place will be important if more proprietary applications are going to be ported to Linux in the future.
Simply wrong, there are already lots of CLI applications on flatpak.
Having to prefix commands with “flatpak run org.whoever.whatever…” gets old quickly, and setting aliases to get around it isn’t user friendly. It’s certainly possible, it’s just not practical (which may have been a better word to use than “feasable” in my first comment).
Let’s paraphrase to “CLI applications are quite cumbersome to use under Flatpak as per the current implementation”.
Unless you set up your own aliases, you’ll have to write out commands like
flatpak run ..., and if you don’t know the package name yet you’ll need to runflatpak list --appfirst as wellI hope that in the future, Flatpak gets some improvements for exporting CLI utilities into the user’s environment.