Writing to /etc or /opt requires root access. Please don't do this.
"Properly packaged"? For which distro? The current way of doing it is distro-agnostic. That's a good thing.
@Preflex - in concept it is distro-agnostic however in practice it is not as it usually breaks more often than not forcing users to hack around by removing c++ abi libs and the such-like.
There is no reason why the supporting libraries needed to provide the "valve abi" could not be put into a repo and folks send pull requests into a distro/ directory that contains the spec files for each distro's flavor of packaging system - PKGBUILD for Arch, rpmspec for Fedora&similar, deb for Debian&similar and so on. These are usually single file declarative scripts. Putting them all under the one unified tree that is considered 'the upstream' is a better approach. Remember all the libraries are open-source ones, libSDL, libstd-c++ and so on..
Duplicate of the other Steam runtime issues here. The specific suggestion is different so I'll keep this open for now.
@gdrewb-valve correct, thanks. I was going to be so audacious as to suggest we could make this as a meta bug for all the related runtime issues that centre around this perhaps more fundamental issue.
Unless I am not understanding this correctly such a configuration would merely mix in the steam-runtime libs with the system libraries as ldconfig would not distinguish between steam and non-steam applications when linking the libs. Since Valve clearly wants to provide libstc and such this would provide two options to satisfy that to the linker for all applications. I could be completely wrong, but there is not way to relate libvalve.conf to steam apps. All the libs would just be mixed into the cache.
Really what would make sense is Valve hosting an internal Open Build Service instance and simply building proper deb/rpm/etc packages for all distros they decide to care about. Other distro are typically based on the big ones or close enough that ABI breakage would be virtually non-existent. I am going to guess that Steam currently is provided compiled binaries and not source to games so that would be a potential issue. Obviously devs could do it, but it has the same hardships as any upstream at that point. Even using appimage would have issues since games have to touch low-level components like driver stuff that will always have to be system provided.
It makes sense from Valve's perspective why they just pick a distro, but it sucks for the rest of us.
Hello @victoredwardocallaghan, influencing all applications outside of Steam makes this approach a non-starter because of the endless complications that can arise that are outside the scope of this project.
We would need some way to isolate the additional ld.so.conf config from the base system and also adapt https://github.com/ValveSoftware/steam-runtime/blob/02dc5d4cdf65a016ba64a273fea963b556eccaa4/templates/run.sh#L21 to retain the current way Steam makes a small high priority pinned library set, followed by system libraries before using the Steam runtime variants.
If that can be figured out, let me know and I can re-open this issue report.
Nothing extracted yet.
LD_LIBRARY_PATHand friends are really just hacks. However Valve Steam requires a stabilized runtime environment in which they can control ABI stability which is understandable.However, the
/etc/ld.so.conf.d/libvalve.confruntime linker configuration mechanism was really designed for this wherelibvalve.confwould be included in the package. Valve could then provide properly packaged libraries and have the runtime linker properly work with those libraries. These libraries could be installed into/opt/valve/{lib,include}.There are many bug reports and issues pertaining to this matter but the matter has never been resolved technically. Hopefully this report should bring about a informed technical discussion on how to do this in a better than how it currently is done.
Cheers,
Edward.