Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#75157 - [steam] Consider adding lib32-nm and lib32-libva as optdepends
Attached to Project:
Community Packages
Opened by Emil (xexaxo) - Friday, 24 June 2022, 17:29 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 20 July 2022, 02:15 GMT
Opened by Emil (xexaxo) - Friday, 24 June 2022, 17:29 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 20 July 2022, 02:15 GMT
|
DetailsDescription:
Similar to [1], which covers fairly critical components, here we look at lib32-nm and lib32-libva. As seen in [2] the bundled libraries are old and buggy. Ideally lib32-libva will be a depends, to avoid high CPU usage during video playback. Keeping lib32-nm as optdepends is reasonable, since Steam can workout NM - and many people do not install it. What do you think? Should I send over some patches? Additional info: * package version(s) steam 1.0.0.74-1 * config and/or log files etc. * link to upstream bug report, if any [1] https://bugs.archlinux.org/task/75156 [2] https://github.com/ValveSoftware/steam-for-linux/issues/8595 |
This task depends upon
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.
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.
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.