Time to sunset the "steam-installer" deb?

[ogra]

@incans

True. But then as Windows users we’ve come to expect that downloading an installer file from the web and then running it locally is the state of the art in user experiences. It’s not exactly “click on a link, go get a cup of coffee and then start browsing the list of games to play” either way.

Well, it would have been pretty exactly this had you decided to install the steam snap that is well integrated with Ubuntu, bundles all the i386 bits it needs, has been developed by a team of Canonical employees and gets regular testing…

You picked the path of using a third party installer instead which is simply not as integrated…

While the steam developers could have added a hack to their package to automatically enable the i386 arch (by breaking Debian packaging policy) they decided not to even though you gave them full root access to your machine

[eeickmeyer]

Hi there,

This is part of (and continuing the discussion between @ogra and @popey about the Steam installer, and I’m moving the conversation here since it merely bikesheds the issue being discussed and doesn’t help the user.

One would think that the first place people should go when installing Steam would be the App Center, which would install the Steam snap and avoid the mess of having to enable the i386 architecture. Likewise, the official Steam .deb from Valve enables the i386 architecture, breaking Debian packaging policy altogether.

Autosynced from Debian is the steam-installer package, and many guides still say this is the way to install Steam on Debian and Ubuntu. Unfortunately, it comes with a caviat: one must enable the i386 architecture manually otherwise it fails.

So, I propose (perhaps in the furture) that we:

• blocksync steam-installer
• Remove steam-installer from the archive
• Add a quirk to ubuntu-release-upgrader to prevent its removal in case of upgrades.

Do note this would not prevent people from downloading the Steam .deb directly from Valve.

I do not propose having steam-installer be a transitional package to the snap simply because that would break existing installations as Steam installs applications to ~/.steam and the snap installs to ~/snap/steam, which would require the user to manually move the library, and this would not be desired.

I do want to note that, in my testing (and as tested by @luisalvarado) that the Steam snap performs just as well if not better than the steam-installer deb or even the official .deb from Valve.

Also note that, in my opinion, GUI methods of installing packages (or doing anything for the end user!) should be favored over command-line installations. GUI installation of the Steam snap is already offered via the App Center, so I’m thinking this should be the preferred method.

This is just a suggestion, and other ideas can be suggested as well.

[ogra]

@incans

True. But then as Windows users we’ve come to expect that downloading an installer file from the web and then running it locally is the state of the art in user experiences. It’s not exactly “click on a link, go get a cup of coffee and then start browsing the list of games to play” either way.

Well, it would have been pretty exactly this had you decided to install the steam snap that is well integrated with Ubuntu, bundles all the i386 bits it needs, has been developed by a team of Canonical employees and gets regular testing…

You picked the path of using a third party installer instead which is simply not as integrated…

While the steam developers could have added a hack to their package to automatically enable the i386 arch (by breaking Debian packaging policy) they decided not to even though you gave them full root access to your machine

[popey]

I love you @ogra but it is my humble opinion that this entire post is 100% factually untrue and/or misleading. Please reconsider posts like this.

@ogra

Well, it would have been pretty exactly this had you decided to install the steam snap that is well integrated with Ubuntu, bundles all the i386 bits it needs, has been developed by a team of Canonical employees and gets regular testing…

I put it to you that the official deb on the steam website gets as much, if not much more testing than the snap inside Canonical. Let’s not overegg the pudding here.

@ogra

You picked the path of using a third party installer instead which is simply not as integrated…

Wrong.

They did apt install steam-installer. Where does that come from? The Ubuntu archive. That’s first party.

apt-cache show steam-installer
Package: steam-installer
Architecture: amd64
Version: 1:1.0.0.79~ds-2
Multi-Arch: foreign
Priority: extra
Section: multiverse/games
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 120
Pre-Depends: debconf
Depends: steam-libs (= 1:1.0.0.79~ds-2), steam-libs-i386 (= 1:1.0.0.79~ds-2), zenity | yad, debconf (>= 0.5) | debconf-2.0
Conflicts: steam-launcher
Breaks: steam (<< 1:1.0.0.75+ds~)
Replaces: steam (<< 1:1.0.0.75+ds~), steam-launcher
Filename: pool/multiverse/s/steam-installer/steam-installer_1.0.0.79~ds-2_amd64.deb
Size: 49364
MD5sum: ae25bc4caf0bf111c6e0ee80f09cdac0
SHA1: e906f59942f043b19ef07e85830501920a9b2d59
SHA256: 0cdc5f4bc8ceb27f55fc9328979db1968d274ca616c97e659258149aa5f93bc8
SHA512: e218e3631734ac42d903a7fc0098ba61c5972ff0aced5ec7ccaf54d09c83215550af3929adb763eac13b2a7da2d5990e173316684178825fe060bbfe50d0af73
Homepage: https://steamcommunity.com/linux
Description-en_GB: Valve's Steam digital software delivery system
 Steam (https://www.steampowered.com) is a software content delivery system
 developed by Valve software (https://www.valvesoftware.com).  There is
 some free software available, but for the most part the content delivered
 is non-free.
 .
 This package provides a script that downloads and installs the Steam
 client, and depends on 32-bit and 64-bit libraries and other components
 that are required by the Steam client. The actual Steam installation and
 all Steam games will be installed into the home directory of each user who
 runs the installer script.
 .
 Because Steam requires 32-bit libraries, before installing this package it
 will be necessary to run, as root:
 .
   dpkg --add-architecture i386; apt update
 .
 Use of Steam is subject to several license agreements and other legal
 terms. Please see <https://store.steampowered.com/subscriber_agreement/>
 and <https://store.steampowered.com/legal/> for more details, and pay
 attention and read carefully if you're worried about your rights.
Description-md5: 1628561328c024db73bb48ba285fc9ad

Indeed, the original problem description states:

Problem Description :
Steam will not install from the standard Ubuntu repos

@ogra

While the steam developers could have added a hack to their package to automatically enable the i386 arch (by breaking Debian packaging policy) they decided not to even though you gave them full root access to your machine

Wrong

The upstream steam deb does exactly what you say it doesn’t do!

$ wget https://cdn.fastly.steamstatic.com/client/installer/steam.deb
$ ar -x steam.deb
$ tar xvf data.tar.xz

Let’s find the code:

$ grep -A 20 "def enable_i386" usr/lib/steam/bin_steamdeps.py
def enable_i386():
    # type: () -> bool

    global _foreign_architectures

    if needs_i386():
        # Check to make sure 64-bit systems can get 32-bit packages
        logger.debug('Adding i386 architecture...')
        cp = run_subprocess(['dpkg', '--add-architecture', 'i386'])
        if cp.returncode != 0:
            logger.warning(
                'An error occurred while enabling 32-bit (i386) packages',
            )
            return False

    # invalidate cache
    _foreign_architectures = None

    return True

Pretty please, with sugar on top, can we stop using every thread as an opportunity to malign one package or another.

Our goal here is and always should be:

Understand the problem being articulated
Solve the problem

Nowhere on that list is:

Telling the user they’re doing it wrong
Maligning a fully supported, endorsed and maintained package selection
Maligning third parties (in this case Valve) for software packaging decisions

Thanks

[ogra]

I was mainly reacting to the “one click install and start playing” claim, which is exactly what the snap provides without having to jump through any hoops…

@popey

@ogra

employees and gets regular testing…

I put it to you that the official deb on the steam website gets as much, if not much more testing than the snap inside Canonical.

I didn’t claim it gets more testing, it gets regular testing and there was a team of four full time developers dedicated to it for the last 1-1.5y to test, play, fix reported bugs etc… if you look at the Linux steam stats valve releases regularly you will notice UbuntuCore (which is how the snap shows to steam in their OS check) comes at fourth place behind Arch, Ubuntu 24.04 and Mint, so I wouldn’t say it actually gets a lot less end-user testing either… But that is indeed in the eye of the beholder

@popey

The upstream steam deb does exactly what you say it doesn’t do!

Well, beyond the point that this pretty much violates the deb packaging policy by secretly modifying unrelated parts of the system only an administrator should change and by abusing the root permissions the deb gets through dpkg (which as you know yourself is one of the very reasons snaps exist at all), it also did obviously not work, else we wouldn’t have this thread…

Note that my reply was not meant to lure anyone into one packaging system or the other, I was literally just reacting to the “oh why is this not done easier” by pointing out that Canonical has actually invested a lot (paying a bunch of full-time devs to play games for more than a year isn’t actually cheap ) to actually make it easier if you simply install steam with one click from the first hit you get in the App Center …

We can talk again when the OP messed up their system by adding the kisak PPA because they found some games need newer mesa (where the snap would just need a simple switch of the mesa content snap without touching the rest of the OS)…

Until then, the first round at the Bar at the next Ubuntu Summit is on me, since I love you as much as you do love me

[popey]

@ogra

Well, beyond the point that this pretty much violates the deb packaging policy by secretly modifying unrelated parts of the system only an administrator should change and by abusing the root permissions the deb gets through dpkg (which as you know yourself is one of the very reasons snaps exist at all), it also did obviously not work, else we wouldn’t have this thread…

Er, I don’t think you’ve read the thread properly, my man.

You’re suggesting something “did obviously not work” that the user did not do.

You’re conflating the valve provided steam.deb (which is the one that does add the i386 foreign arch) and the steam-installer (which the OP used) from the Ubuntu archive, which didn’t work.

Also Valve is far from alone in ‘violating’ the deb packaging policy - which doesn’t apply to 3rd party debs from external repos anyway… Microsoft Edge, Google Chrome, and a ton of others do this.

Sure if they’d used the snap or the steam.deb from valve, we wouldn’t have this thread. But as they say “If ifs and buts were candy and nuts, we’d all have a merry Christmas”

(Arguably the real question is why i386 wasn’t enabled by default on OPs system. I am somewhat confident it is by default, but don’t know how to check without doing a clean install. The reason I say this is because it broke a few releases ago, and was re-fixed to be on by default)

[ogra]

Heh,. now you made me download and inspect the steam-installer package

I was actually (since forever) under the impression it downloads the steam.deb and installs it, but digging though the code it pulls a few random tarballs and extracts them into your home dir, so mea culpa here, I assumed wrong …

Looking deeper though, the steam-installer isn’t even touched by Ubuntu devs though (beyond some metadata adjustments), it is synced from debian and maintained by the Debian Games team …

[eeickmeyer]

I propose (perhaps in the future) that we:

• blocksync steam-installer
• Remove steam-installer from the archive
• Add a quirk to ubuntu-release-upgrader to prevent its removal in case of upgrades.

Do note this would not prevent people from downloading the Steam .deb directly from Valve.

I do not propose having steam-installer be a transitional package to the snap simply because that would break existing installations as Steam installs applications to ~/.steam and the snap installs to ~/snap/steam, which would require the user to manually move the library, and this would not be desired.

I do want to note that, in my testing (and as tested by @luisalvarado) that the Steam snap performs just as well if not better than the steam-installer deb or even the official .deb from Valve.

Also note that, in my opinion, GUI methods of installing packages (or doing anything for the end user!) should be favored over command-line installations. GUI installation of the Steam snap is already offered via the App Center, so I’m thinking this should be the preferred method.

This is just a suggestion, and other ideas can be suggested as well.

[ogra]

I was actually wondering about this when talking to popey, but came to the conclusion that it isn’t really up to me to make such a decision… Should such a thing perhaps be discussed with the tech board?

[eeickmeyer]

Perhaps. In my mind it would be a Desktop Team or Foundations-level decision, not so much a TB decision, but roping the TB in on this isn’t a bad idea.

[ogra]

Right, just someone who doesn’t work as IoT field engineer as his first job would be better

[incans]

@eeickmeyer

I propose (perhaps in the future) that we:

• blocksync steam-installer
• Remove steam-installer from the archive
• Add a quirk to ubuntu-release-upgrader to prevent its removal in case of upgrades.

Oh dear. The last thing I would have wanted to do was inadvertently precipitate the loss of yet another major application from the primary distro repository into a “sandboxed only” walled garden.

[popey]

Thanks for starting this thread @eeickmeyer. I certainly think this is an opportunity to do some positive things around the Steam Snap.

However, I think before we just pull the plug on the deb, we should have a plan for the rather janky setup process and strange UI bugs which appear to be known, but not tracked that I can see.

Just some examples after looking at the steam snap in a brand new install, for less than 30 minutes, with my “new user hat” on.

I am not saying these are showstoppers, just pointing out that it’s not as plain sailing as “just click install in the app center”. This needs to be especially noted for our novice users (who we see around here a lot), for whom some of these things are quite the challenge.

NOTE: I am not asking anyone here to solve any of these, or discuss the solutions here. My point in raising them is to demonstrate that the experience in using the snap is far from what I’d expect, if the previously accepted ‘default’ way is being removed.

1. The store page is incredibly sparse. It does link to the git repo which is scary enough for new people.

But that then has a giant banner (unfathomly, at the bottom, which is weird IMHO), " For questions and troubleshooting, see the wiki."

2. There appear to be unacknowledged weird issues with the UI. I found mention of it in the issues, but nobody seemed to say anything. When I installed my first game, the UI said it would install to /usr/lib/modules which is somewhat alarming! I tried adding another drive, and now both of them show up as /usr/src.

Which results in this when I try to install. Which is a little confusing.

3. I recorded some gameplay, and when I tried to export it to a folder, “something went wrong”

4. Searching (on Google, Kagi, Bing, ChatGPT, startpage, askubuntu) online shows a very large number of article, threads, blogs etc pointing to steam-installer.

This is all “out of the box”, with no messing around by me. Just trying out some basic things.

Again, I am not looking for anyone to solve the things that I found for me. I am merely highlighting the less than stellar quality of the experience.

Ok, let’s flip to positivity mode:

My proposals:

a) The store page needs a lick of paint, and should target new people, who are more likely than not going to hit these rough edges. It should signpost the wiki, and at the very least contain the snap connect details found in the wiki

b) Improve documentation for the stock experience. Perhaps loop in some community people to make videos detailing how to install steam in 25.10.

c) Have a Steam Snap testing day/week. So we can uncover these bugs, rather than have people just see them, and rage quit to the official deb without telling us what went wrong.

d) Have some people focused on working on those issues, so we can improve the snap experience.

Again, I’m just some guy, running Steam Snap and finding immediately there are issues. If I can stumble over these, there have got to be others with these issues, because I didn’t stretch this in any way.

I’d be happy to help with any of the above, but it can’t be down to one person, and this needs to be done before anyone yanks/blocks steam-installer from the archive.

Thanks.

[eeickmeyer]

That’s not the purpose, and please do not call snaps “sandbox only” walled gardens. That serves no purpose here, we don’t allow snap-bashing at all on this Discourse as it’s completely wrong and off-topic for this discussion. I will not hesitate to remove posts that go off-topic.

Did you even read what I wrote? There would be nothing preventing the official .deb from Valve from being installed; we’d just offer the snap as the first option. It’s just the Debian-synced package that is in question here.

[eeickmeyer]

@popey

I tried adding another drive, and now both of them show up as /usr/src.

It’s just me, but after installing I immediately connect the snap to all available connections, including removable-media and mount-observe. I think that’s the key in this case.

For me, I created a spot on my / drive (which it sees as /boot as a removable drive) and the regular one in my /home directory, which is on its own drive. It shows up like this, with the above connections made:

When selecting in “Settings/Storage”, it gives me the full path of the directory:

I even got this under the .deb version, so it could be that the Windows-centric nature of Steam just sees devices under Linux weirdly.

For what it’s worth, the available snap connections are as follows:

audio-playback                gtk-3-themes                  removable-media
audio-record                  hardware-observe              screen-inhibit-control
bluez                         home                          shmem
desktop                       icon-themes                   sound-themes
desktop-legacy                joystick                      steam-support
dot-local-share-applications  mount-observe                 system-observe
dot-local-share-icons         network                       uinput
dot-local-share-steam         network-bind                  upower-observe
fuse-support                  network-control               wayland
gaming-mesa                   opengl                        x11
gsettings                     process-control

Personally, I find that having them all connected is the best experience.

Not to bikeshed or anything, but when I did the drive arrangement originally it was because my /home was on a spinning hard drive, and wanted certain games to run faster on an SSD.

[popey]

@popey

NOTE: I am not asking anyone here to solve any of these, or discuss the solutions here. My point in raising them is to demonstrate that the experience in using the snap is far from what I’d expect, if the previously accepted ‘default’ way is being removed.

Thanks. But again, I am not asking us to solve these issues here, or solve them for me. I am not the target here. I am trying to highlight issues that need better documenting, or fixing.

[eeickmeyer]

Sure, I understand that. I was being completely anecdotal.

The “issues that need … fixing” part would require the devs of this snap to get special permissions via forum.snapcraft.io to have those pieces I mentioned above autoconnected, as I’m sure you well know.

[luisalvarado]

For anyone following on the conversation, I do mean to do a test with the following games

Thats 10 games that will show the FPS difference between the Steam DB and the Steam Snap.

Last time I tested the snap one surprise me a lot and the only issue I found was the detection of games in the home steam folder (it only read the steam games in external storage devices not inside the home) and an issue with mangohud not using the compiled global version I use.

But both of those are trivial issues. I will be testing again once the games are downloaded to show:

• FPS Performance
• Latency or Stuttering issues like CS2 having stuttering on DEB when on SNAP it did not have any.
• Controller Support (PS4, PS5)
• Storage Detection
• Anything else I can perceive using the default settings for both and no tweaking whatsoever so I get as close as possible to the experience someone using one or the other will have.

Hardware is always mentioned in the youtube videos so thats that.

Note that the issue mentioned by @eeickmeyer about the Local Drive() thing also happened to me after last steam update (Not related to DEB or SNAP but the steam client). It also stopped seeing my bigger external drive which is 8TB. Will see how the Snap version handles this too

[mlorenzo]

I fail to see what’s the advantage of having a Snap for Steam, considering that Valve is maintaining the Deb package and even aiming it at Ubuntu, and that we have this steam-installer in Ubuntu repositories that just eases the installation of required dependencies.

That point is clearer for packages as Firefox, where a single package can be maintained for the different versions. But, Steam?

What is the rationale for Canonical to expend that huge amount of developers time in just a distribution package that will need to be maintaned by the same Canonical? How do we benefit as users using the Snap?

[popey]

@mlorenzo

I fail to see what’s the advantage of having a Snap for Steam

Is this a genuine question?

The reason I ask is that over the last 8 years I’ve worked on Snaps, I have heard, “Why does this exist?” asked so many times, despite already being answered or documented elsewhere.

Sometimes, it comes from a real sense of curiosity, asked by someone who actually doesn’t understand the benefits of Snaps. Other times, it’s just used as a vehicle to berate developers for working on something they don’t like.

Plenty of people here could answer all your questions in detail. But that would be a colossal waste of their time, if the question is not from a place of respect and curiosity.

Which is it?