Support me on Patreon to keep GamingOnLinux (and me) alive. Funding me on Patreon allows us to have no adverts, no paywalls, no timed articles. Just good content for you to keep up with Linux gaming. Alternatively, you can support me on Paypal.

Steam is now available as a Flatpak app via Flathub

Posted by , 19 June 2017 at 10:30 am UTC / 4670 views
Flathub [Official Site], a 'central hub' for Flatpak [Official Site] applications have now made a Flatpak of Steam available for Linux users.

Note: I've not used Flatpak at all myself, nor have I tried out this Steam Flatpak as I don't want any issues with my existing install.

Found on the github for Flathub is com.valvesoftware.Steam, where you can find out more about what it's doing. While it is unofficial, Valve could request access if they wished to take control of it, according to this comment on github.

The actual Steam download itself is little more than another downloader anyway, which then downloads the full Steam application. The Flatpak for Steam doesn't actually contain the Steam downloader, looking at the JSON file, it actually links to the official downloadable tar.gz from Valve. Steam also updates itself, so it's possibly one of the less important applications for Flatpak. While Flatpak is claimed to be more secure than .deb and .rpm, there's a lot of conflicting information and opinions on that.

Having a proper cross-distribution package management tool will benefit Linux quite a lot in the long run, at least that's what I think anyway. Being able to download and update any application I want and be up to date no matter the distribution is very appealing.

If you want to read more about Flatpak itself, check the official FAQ.

Thanks to AsciiWolf for the email tip!
Comments
Page: «2/3»
  Go to:

natewardawg 19 June 2017 at 2:52 pm UTC

This is very cool news

I have to admit that flatpak seems much easier to use now than when it first came out. And due to that I no longer have much of an opinion as to which universal distribution model becomes the dominant one


meggerman 19 June 2017 at 3:09 pm UTC

Can anyone confirm if this works with Games not installed on /home drive ? I have my games on a larger mounted HDD. This works for me as the drive is partitioned and contains other files too. Having to use the Home drive would kind of suck for me, not only that it means my distro hopping gets a lot more convoluted as i either have to re-download my games / mods each time i rebuild or copy the files to a larger disc and back again hoping that there is no corruption and/or permission issues ( I have had the "steam library folder must be on a filesystem mounted with execute permissions" bug before when moving in this manner on new systems. Also the 'backup feature doesn't work on Steam )

As an aside i also just like to keep as many non system folders and files off my main root drive as possible for reasons.


Last edited by meggerman at 19 June 2017 at 3:10 pm UTC


poiuz 19 June 2017 at 3:25 pm UTC

meggermanCan anyone confirm if this works with Games not installed on /home drive ?
This should work without a problem (my games are on a /mnt/-mounted partition). But you have to allow access to the directory with --filesystem=<DIRECTORY> (either via flatpak run for each application start or flatpak override to persist the setting) or else you won't be able to access it.


Mountain Man 19 June 2017 at 3:28 pm UTC

g000hWaiting for the day that Steam client for Linux is 64 bit..
What benefit would Steam gain from being 64-bit? You can install and run 64-bit software through Steam, so what does it matter if Steam itself is 64-bit?


liamdawe 19 June 2017 at 4:35 pm UTC

poiuz
meggermanCan anyone confirm if this works with Games not installed on /home drive ?
This should work without a problem (my games are on a /mnt/-mounted partition). But you have to allow access to the directory with --filesystem=<DIRECTORY> (either via flatpak run for each application start or flatpak override to persist the setting) or else you won't be able to access it.
Well that sounds rather unfriendly, hope they make that much easier in future.


Kuduzkehpan 19 June 2017 at 5:53 pm UTC

*.RUN files *.BIN files *.SH files are already linux generic executables and installers. just like
*.MSİ *.EXE *.BAT files as in windows. also tgz deb pisi rpm much more native i guess.
meanwhile snappy package format much more better developped for Ubuntu Linux and has more packages why bother with flatpak or appimage or something else along the way. plus containering sandboxing is good but what about library loading and usage with these library container package formats ?

i mean we have to have Common Standarts For linux distrubutions. so we can advance much more faster then ever.


Mal 19 June 2017 at 6:14 pm UTC

g000hWaiting for the day that Steam client for Linux is 64 bit..

Dunno. The day the steam client will need more than 4 Gb of ram I may start to have an issue with it in the first place.


liamdawe 19 June 2017 at 7:25 pm UTC

Kuduzkehpan*.RUN files *.BIN files *.SH files are already linux generic executables and installers. just like
*.MSİ *.EXE *.BAT
None of which come close to helping solve issues that Flatpak is aimed at.


Purple Library Guy 19 June 2017 at 10:33 pm UTC

I kinda like Flatpak, but it seems to me like a useful secondary thing rather than something that can or should kill .deb or .rpm and apt and so on. Like, it could be handy for exactly this kind of thing--closed applications not interested in packaging themselves for different distros and who, since they're closed, the distros can't package themselves. Of course, one significant kind of closed source application like that is games. So Flatpak could be a great thing for our purposes.

Aside from that, it could be handy for things with specific and weird dependencies, like on library versions significantly different from whatever is more or less current; you could keep the distro overall cleaner by doing Flatpaks of such things and keeping the weird versions separated from everything else. But for the most part, I think solid dependency management allows a much leaner system and enforces a kind of quality control that's probably a good idea anyway. And apt and similar things for non .deb distros work very well for the most part, as do most of their gui front ends. I'm not sure I think the duplication that would come from Flatpak-for-everything would be worth whatever advantages it would be supposed to have.


Ananace 20 June 2017 at 7:01 am UTC

Purple Library GuyI kinda like Flatpak, but it seems to me like a useful secondary thing rather than something that can or should kill .deb or .rpm and apt and so on.

It's worth noting that Flatpak is not designed to compete with system package managers, which neither Snappy nor AppImage are trying to do either.

Flatpak is designed for packaging userland applications in a way that means users don't have to worry about dependencies, and the sandboxing means you don't have to worry about broken code damaging your system either.
Additionally, it can be run entirely in a user's home, so users don't need to pester sysadmins about installing applications or dependencies - nor about keeping them up-to-date.

I'm actually more of a fan of Flatpak than Snappy in this particular case, Snappy requires a system daemon while Flatpak only requires an application in PATH - on a new kernel it doesn't even require setuid.


  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. We also accept Paypal donations! If you already are, thank you!

Due to spam you need to Register and Login to comment.


Or login with...

Games & Release Calendar
Livestreams & Videos
Popular this week
View by Category
Contact
Latest Forum Posts
Facebook