On Tue, 2016-03-22 at 11:24 +0500, Alexander E. Patrakov wrote: > [readding the list] > 22.03.2016 05:56, Ahmed S. Darwish пиÑ?еÑ?: > > > > On Mon, Mar 21, 2016 at 10:01:14AM +0100, David Henningsson wrote: > > > > Alexander mentioned the SteamOS case, where "they don't link > > statically, but have a 'known-good' copy of the library packaged > > and put into LD_LIBRARY_PATH, and it may be next to impossible to > > explain to the users how to upgrade it." > It is about the standalone Steam client, not SteamOS... > > > > > > > I'm sure though that even if they have a 'known-good' copy, they > > keep the daemon version in-sync with the library version? I can't > > think of any sane reason not to do so.. > So they don't. > > > > > Anyway, if that case is indeed problematic, maybe we can lobby > > them a bit to do a proper distribution of PA? If anyone has some > > contacts, I'll be glad to open a communication channel.. > It is impossible. They connect to a distribution-provided daemon. So > all > we could reasonably do is to ask them to rely on the system- > installed > libpulse (including the 32-bit version). Steam OS only exposes a very very minimal amount of the "host" libraries to games (essentially libc6, X11 and the GL stack iirc) everything else comes from a static runtime which is also what the games are tested against (which has an older libpulse). For exceptions there has to be a very strong rationale and a even stronger guarantee that things won't break. Tbh, i don't think that's likely to happen for this, if the change of the default turns out to be a problem, the default will simply be changed ;) > Also, I have performed some research on games available via gog.com > or > in the past Humble Bundles that have a native Linux version. It > seems > that games that bundle libpulse are rare there, if they exist there > at > all (0 copies of libpulse found in 12 randomly chosen games), which > is a > good news. > -- Sjoerd Simons Collabora Ltd.
