Arch Linux

lib32-libnm and lib32-libva are already dependencies of steam-native-runtime.

This bug is against the steam package, not the steam-native-runtime.

Even though I agree with the goals behind steam-native-runtime, it produces another set of issues (unfortunately). So one cannot realistically argue that steam package will be "fixed" by installing the steam-native-runtime.

That's a hard no on having lib32-nm, even as an optional dep. Arch doesn't force onto anyone the usage of any particular network manager. lib32-libva is also hardware dependent, it isn't all hardware that can benefit from using it, and there are two hardware accelerated video libraries, not just one. The steam-native-runtime has these dependencies covered already.

The wiki describes `optdepends` as `An array of packages that are not needed for the software to function, but provide additional features`. Which is exactly what I'm proposing here.

Yes, Arch does not enforce any specific network manager - hence it being optional. Consider the following scenario: one is using network-manager (libnm), they are also using steam. They have not installed lib32-libnm, since the optdepends is MIA, so they get a subpar experience with steam's network handling.

The libva frontend is required, a backend driver is not mandated. In a similar way to how ffmpeg requires libva, but the driver is optional. Aside: technically we should have a virtual libva-driver, similar to opengl-driver - but that's for another day.

Not sure I see the steam-native-runtime point you're trying to make. It pulls 100+ extra packages, well over 150 MiB on my system, where the proposal pull approximately 2MiB on my machine - difference of 75x. The steam-native-runtime a separate package, while the 2 extra deps relate directly to steam.

In addition, the steam-native-runtime approach of explicitly disabling the SRT is not encouraged nor supported by Valve. From my personal experience has steam-native-runtime has more compatibility issues than using steam directly.

My point is, steam will use their own runtime libraries. That's the point in them having a runtime. If their runtime has outdated libraries, that's a different story and you should take that up with valve directly. Also, it's not all video drivers that support VAAPI. Given that there are a lot of nvidia users out there, should we also bring in lib32-nvidia-utils as dependency? What about AMD? See where I'm going with this? Also, regarding your personal experience with steam-native-runtime, I would expect bug reports. Because I have been using steam (beta channel) with steam native runtime for years now without issues.

For a few years now, the steam startup script has been promoting host libraries and using them instead of the bundled SRT ones. Over time that list grew - libnm and libva being the latest additions. Who knows - one day we steam and steam-native-runtime may become the same. Currently we're not there yet.

The developer who did the change in the steam script literally recommended that distributions would (ideally) be shipping newer versions of lib32-libnm, lib32-libva etc. I believe the steam package in Debian was reflected to cover that - not sure about other distributions.

As I said before - the libva _frontend_ is required, the backend is _optional_. For people that have hardware with decent libva backend - great. Sadly nvidia users do not, so they can live with the 300K lib32-libva.

Humble poke anyone?

Given the finding at https://github.com/ValveSoftware/steam-for-linux/issues/9805#issuecomment-1626486059 I would also add lib32-libudev0-shim to the list.

There are a bunch of other (opt)dependencies that should be added:

https://bugs.archlinux.org/task/74827
https://bugs.archlinux.org/task/75155
https://bugs.archlinux.org/task/75443
https://bugs.archlinux.org/task/75590

In a bunch of these the suggestion is to install steam-native-runtime, which AFAICT is not supported by Valve.

Would be really appreciated if maintainers can spend some time through the steam bugs. Thanks in advance

You can install steam-native-runtime to pick up all of these deps and not start steam in native mode regardless. You'd basically duplicate the entire dep list of steam-native-runtime for optdepends-to-try in case steams runtime is broken, in which case you are logically back at picking up steam-native-runtime eventually anyway.

@V1del: Exactly. That's what I've been saying this whole time. I have both steam-native-runtime and wine-staging installed including all optional dependencies. I almost never have issues with Steam.

I'm trying to put a comprehensive list of what we need to add to steam-native-runtime, and what is actually steam bugs.

Pretty hyped on caffeine, so I hope the following makes sense ... somewhat :-)

@grazzolini I realise it sounds selfish but I would suggest going through all my steam issues. They will give you a good enough baseline of what needs to be added/fixed in the steam package. Adjusting (fixing or otherwise) steam-native-runtime is nice, but should probably be looked separately.


For the longer version, continue reading below:

Let me see if we can unwrap this up - starting with the basics, to be on the safe side.

Currently there are two types of Steam Runtime - Ubuntu 14 (I think) chroot and container based ones. The latter are non-issue as far as we're concerned.

The former uses promotion of system libraries. Initially I _think_ very few libraries were in the allow list. These days a handful are in the "must use non-system library" list. Given the current promotion design, it's quite likely to get ABI issues like the Github linked one. The linked Arch bugs should be considered the bare minimum to handle otherwise avoid the vast majority of issues. Each one of those is "inspired" by an actual bug people were observing - they are not pulled out of thin air.

Now looking at steam-native-runtime (s-n-r) itself - it includes:
- an absolutely massive list of packages, which is understandable it replicates (almost?) everything in the runtime
- it includes the "steam-native-runtime" script, which disables the steam-provided one - explicitly not supported and is bound to backfire

One should seriously consider those points when suggesting s-n-r: do people need to install the extra (58 by my count) lib32 and other packages? how likely are people to _not_ use the unsupported steam-native-runtime script?

There is another point as well: suggesting to install s-n-r is like telling people who slipped/broke their leg is that they should drive. It's true and has merit, although completely off point. Sort of like https://en.wikipedia.org/wiki/Let_them_eat_cake if you will. I agree the analogies are pretty silly, but should be rather indicative.

IMHO the better option is to:
- start adding dependencies, as they are uncovered to be problematic
- optionally: drop the said dependencies from s-n-r

With time I'm anticipating that steam will inherit nearly all the dependencies from s-n-r with the latter becoming a simple the fancy shell script and just a handful of package deps.


As a closing thought:
I am deeply grateful for the people who helped maintain steam (and Arch as a whole). At the same time, it is very disheartening when even trivial changes receive zero response in over one year. Maintainers, please tell us how we can help you.

Thanks for sticking until the end.

Humble poke? Can I help move this forward?