Lutris version 0.5.10 brings improved Steam Deck support but no Flatpak yet

Quoting: DerpFox

Quoting: pleasereadthemanualFlatpak tackles some long-standing distribution issues with GNU/Linux. It's not perfect, but something like it needs to exist in the future in order to deal with these problems that simply don't exist on macOS or Windows.

So do the "others". And each one of them have their own set of good and wrong. The one I had the least problem with is AppImage, and I don't particularly like it, it has plenty of design problems but each one I tried worked flawlessly. The one I want to try the most is Flatpack but each time I tried it was a huge pain in the ass to set up, didn't understand how I should do it, and it keeps throwing errors at me. Their doc makes it look easy, but when you get errors, you are on your own and good luck to find what they mean. And it seriously lacks a GUI to make installation fast and easy.

discover, gnome appstore and others are there to help you install flatpaks. Flatseal to configure it.

Quoting: pleasereadthemanualFlatpak tackles some long-standing distribution issues with GNU/Linux. It's not perfect, but something like it needs to exist in the future in order to deal with these problems that simply don't exist on macOS or Windows.

The downsides are that a lot of developers don't maintain their own Flatpak packages (or one doesn't exist at all), the sandbox is flawed, Flatpaks can introduce issues that didn't exist before due to its complex nature, it may be slower (at least in startup time), and the syntax for the package manager is just not as good as Pacman. Storage space is less of an issue the more Flatpak software you install.

Flatpak is another in a long line of 'we don't want to manage packaging for multiple distributions' solutions. There have been installer type things for ages in Linux that work the same way as Windows. Flatpaks are a little more similar to how Macs package things.

Downsides are that the sandboxing can break integration (like Discord with Steam), or Lutris with its wmulators. Another one is because it doesn't follow the system libraries, you could end up with explouted versions if the Flatpak isn't updated. Which has always been an issue with bundled software. They also take up a lot more disk.

Don't get me wrong, I quite like flatpaks, but the Cons definitely all need to be listed. AppImages have similar issues, but have also been around quite some time, and act more like the 'Mac Way'.

Looks like Debian Sid already has 5.10. Yay! Time to play around with it.

[quote=const]

Quoting: DerpFoxdiscover, gnome appstore and others are there to help you install flatpaks. Flatseal to configure it.

Yeah, cool but, as always, that's third parties that comes to compensate what the main project lack. That model is getting a bit tiresome because more often than not these third parties doesn't integrate well with the main project and add their own set of shortcoming and problems to the stack.

[quote=DerpFox]

Quoting: const

Quoting: DerpFoxdiscover, gnome appstore and others are there to help you install flatpaks. Flatseal to configure it.

Yeah, cool but, as always, that's third parties that comes to compensate what the main project lack. That model is getting a bit tiresome because more often than not these third parties doesn't integrate well with the main project and add their own set of shortcoming and problems to the stack.

Flatpak is part of the gnome project so the GNOME appstore is part of the main project that flatpak is also part of.

Flatseal is a separate project however, so far in my experience I've never needed to use it, inst the point of flatpak to be plug and play.

Quoting: slaapliedjeFlatpak is another in a long line of 'we don't want to manage packaging for multiple distributions' solutions. There have been installer type things for ages in Linux that work the same way as Windows. Flatpaks are a little more similar to how Macs package things.

Downsides are that the sandboxing can break integration (like Discord with Steam), or Lutris with its wmulators. Another one is because it doesn't follow the system libraries, you could end up with explouted versions if the Flatpak isn't updated. Which has always been an issue with bundled software. They also take up a lot more disk.

Don't get me wrong, I quite like flatpaks, but the Cons definitely all need to be listed. AppImages have similar issues, but have also been around quite some time, and act more like the 'Mac Way'.

Note that I said "or something like it". I prefer AppImages, personally, but the Flatpak package I tried worked fine. Better than my distribution's package, which was broken for several weeks.

You mention other "installer type things", but I'm assuming you're referring to .sh install scripts. These are not really the same thing as Windows or macOS. For one thing, depending on how they're implemented, they may not solve the dependency issue at all. They're also often difficult to uninstall and create havoc on the user's system. Flatpak and AppImage are not like this.

I listed these cons in the comment you quoted, namely "Flatpaks can introduce issues that didn't exist before due to its complex nature", and "Storage space is less of an issue the more Flatpak software you install." Of course, you can end up with multiple versions of libraries which Flatpak can't de-duplicate due to compatibility issues, but then, your options are "don't run it at all" or "use more disk space".

I'm not sure what you mean by "because it doesn't follow the system libraries, you could end up with explouted versions if the Flatpak isn't updated." But it doesn't follow system libraries for a reason: if it did that, the software would break. There is old software that simply can't be run with current system libraries and needs older dependencies, which without something like Flatpak, is a lot harder to get running.

A downside I forgot to mention is that because Flatpaks duplicate system libraries if they are installed by your distribution's package manager, you will end up with more memory usage because multiple versions of the libraries are running at once. There's not much that can be done about this one. It's a similar issue to storage space, but potentially more impactful.

If you're interested in reading an article written by someone who completely disagrees with my arguments: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html

Though this advice isn't going to work for projects that have a long legacy and just aren't easy to build. Arch and almost every other distribution has stopped bothering to package Anki for the past 2 years because it's too much work. Where is the user left? Follow the developer's advice to install it through pip?

I'm not saying that Flatpak should replace distribution-built packages. I'm saying they should co-exist.

Quoting: DerpFox

Quoting: pleasereadthemanualFlatpak tackles some long-standing distribution issues with GNU/Linux. It's not perfect, but something like it needs to exist in the future in order to deal with these problems that simply don't exist on macOS or Windows.

So do the "others". And each one of them have their own set of good and wrong. The one I had the least problem with is AppImage, and I don't particularly like it, it has plenty of design problems but each one I tried worked flawlessly. The one I want to try the most is Flatpack but each time I tried it was a huge pain in the ass to set up, didn't understand how I should do it, and it keeps throwing errors at me. Their doc makes it look easy, but when you get errors, you are on your own and good luck to find what they mean. And it seriously lacks a GUI to make installation fast and easy.

I remember having a bad experience with Flatpak a few years ago, but I tried it two weeks ago, and the process was as simple as installing Flatpak and following the on-screen instructions for the Flatpak package (which was [code]flatpak install flathub org.gnome.Evolution[/code]). Given I don't really use Flatpaks much (and I've since removed this package after Arch fixed Evolution), I don't know how much worse it gets.

I said "something like it needs to exist," not necessarily Flatpak. But it's pretty obvious AppImage is not going to win the mindshare battle.


Last edited by pleasereadthemanual on 4 April 2022 at 9:12 am UTC

Quoting: pleasereadthemanualYou mention other "installer type things", but I'm assuming you're referring to .sh install scripts. These are not really the same thing as Windows or macOS. For one thing, depending on how they're implemented, they may not solve the dependency issue at all. They're also often difficult to uninstall and create havoc on the user's system. Flatpak and AppImage are not like this.

Just for the sake of historical accuracy: Besides shell scripts there were things like InstallShield (basically still a script) available as distribution agnostic installers. Also, both of these things were pretty much exactly the same thing as Windows used for everything at the time (before the Microsoft Installer package manager existed). It's still possible to find Windows programs that use a script instead of a proper .msi package. Of course the scripts were only as good as the person creating them took the time for. However, generally, these old install scripts installed programs in /usr/local or /opt and didn't leave a mess behind (the weaker ones usually just left you with dependency issues for the so-called "installed" software they were for). You were more likely to get a mess when compiling software and using the 'make install' target that the developer created for make (though there were ways to deal with that cleanly as well).

The universal installer idea for Linux isn't very new. There were things like Zero Install (still maintained last I knew) and Klik (which AppImage is based on) quite a while back.


Last edited by CFWhitman on 4 April 2022 at 3:09 pm UTC

Quoting: CFWhitman

Quoting: pleasereadthemanualYou mention other "installer type things", but I'm assuming you're referring to .sh install scripts. These are not really the same thing as Windows or macOS. For one thing, depending on how they're implemented, they may not solve the dependency issue at all. They're also often difficult to uninstall and create havoc on the user's system. Flatpak and AppImage are not like this.

Just for the sake of historical accuracy: Besides shell scripts there were things like InstallShield (basically still a script) available as distribution agnostic installers. Also, both of these things were pretty much exactly the same thing as Windows used for everything at the time (before the Microsoft Installer package manager existed). It's still possible to find Windows programs that use a script instead of a proper .msi package. Of course the scripts were only as good as the person creating them took the time for. However, generally, these old install scripts installed programs in /usr/local or /opt and didn't leave a mess behind (the weaker ones usually just left you with dependency issues for the so-called "installed" software they were for). You were more likely to get a mess when compiling software and using the 'make install' target that the developer created for make (though there were ways to deal with that cleanly as well).

The universal installer idea for Linux isn't very new. There were things like Zero Install (still maintained last I knew) and Klik (which AppImage is based on) quite a while back.

Thank you for the correction. I've only recently become a GNU/Linux user, so I don't have first-hand knowledge of what the landscape was like 10+ years ago. No one seems to mention these distribution methods in the histories I've read. The InstallShield Wikipedia page only mentions that it's used for Windows: https://en.wikipedia.org/wiki/InstallShield

I don't know how it was back then, but a considerable number of the scripts I've used in the past year or so didn't have uninstall scripts.

Quoting: pleasereadthemanualThank you for the correction. I've only recently become a GNU/Linux user, so I don't have first-hand knowledge of what the landscape was like 10+ years ago. No one seems to mention these distribution methods in the histories I've read. The InstallShield Wikipedia page only mentions that it's used for Windows: https://en.wikipedia.org/wiki/InstallShield

Well, the only part that perhaps could be considered a 'correction' would be that Windows used to be dependent entirely on install scripts. I thought of the post as more of a clarification. I seem to remember that there were two of the major Windows installation script makers that had a Linux version, but I couldn't remember offhand what the other one was. I don't want to mislead you; InstallShield* and its like for Linux were never popular. But then, neither was anything else along those lines really. Generally only the odd proprietary programs used a shell script installer, but they were still more common than the programs that used an InstallShield installer.

A number of shell scripted installers did have an uninstall target (sometimes you would just run the script with --uninstall, or something like that, if there wasn't a separate uninstall script), but you couldn't count on that. It was just that since the software was all installed in subdirectories of /usr/local or /opt, it wasn't that hard to uninstall manually even if there was no uninstaller. If a program put a launcher in the system menu, you had to do a bit more to get rid of that.

Installation from 'make install' however, would put files all over the place. If the program didn't have an 'uninstall' target, then it would be a big time pain to try and remove one of them. There were things like checkinstall that would keep track of what 'make install' did or 'catch' the 'make install' changes and incorporate them into a package rather than letting them install directly.

*(InstallShield X article in Linux Journal


Last edited by CFWhitman on 5 April 2022 at 12:29 pm UTC