Canonical's Steam Snap is Causing Headaches for Valve - OMG! Ubuntu
www.omgubuntu.co.uk
Canonical may be ramping up its efforts to improve the Ubuntu gaming experience — yasss — but it seems their Steam snap package is causing a few headaches

Timothée Besset, a software engineer who works on the Steam client for Valve, took to Mastodon this week to reveal: “Valve is seeing an increasing number of bug reports for issues caused by Canonical’s repackaging of the Steam client through snap”.

“We are not involved with the snap repackaging. It has a lot of issues”, Besset adds, noting that “the best way to install Steam on Debian and derivative operating systems is to […] use the official .deb”.

Those who don’t want to use the official Deb package are instead asked to ‘consider the Flatpak version’ — though like Canonical’s Steam snap the Steam Flatpak is also unofficial, and no directly supported by Valve.

    • m-p{3}@lemmy.ca
      9·
      10 months ago

      Maybe they’ll get there eventually, considering this is their method of choice for installing 3rd party apps on SteamOS 3.0.

      • OsrsNeedsF2P@lemmy.ml
        7·
        10 months ago

        Steam’s runtime is already sandbox-ception. Flatpak might be more appealing to Valve than it seems.

        • superbirra@lemmy.world
          1·
          10 months ago

          I see no value in switching from current situation (in-repo deb pkg + steam autoupdates) to flat/snap/farts, which I don’t use at all…

          • OsrsNeedsF2P@lemmy.ml
            4·
            10 months ago

            It’s not about you, it’s about what’s easier for Valve. If Valve is fine packaging, and getting bug reports, from all the different distributions, they’ll keep doing things as is. But as a Linux app developer myself, I exclusively publish to Flatpak because it guarantees everyone has the same system.

            • superbirra@lemmy.world
              2·
              10 months ago

              you’re at best uninformed about how the process actually works and what’s the role of a distro maintainer, a distro project, upstream authors. Not that every piece of software has enough value to be included in this process so maybe it will make sense to package your stuff by yourself.

        • Falcon@lemmy.world
          2·
          10 months ago

          Well, no, neither approach is better than the other, it’s apples and oranges.

          There will always be a place for installing native applications. In the least analysis, the container itself should probably have some dependencies packaged for the target program.

          The benefits of containerisation are obvious, but it’s been a lot of work and there are still edge cases to iron out.

          FreeBSD has had jails since 2000. Linux, however, only got namespaces in 2008 and the first bubblewrap release on GitHub was 2016.

          I’ve been using chroots and containers for development for about 2 years now and it’s been fantastic, however, I’m still grateful I don’t have to jump inside one every time I need to write a python script.

          • barsoap@lemm.ee
            1·
            10 months ago

            I’m still grateful I don’t have to jump inside one every time I need to write a python script.

            Honestly, I’m on NixOS and it’s not a bother because it saves time down the line when your script would break during a system upgrade which it doesn’t on NixOS as without you telling it to, it will still use all the old dependencies. Also you already have a couple of flake.nix floating around you can just copy and adjust and direnv does the rest.