On 11/08/16 10:57 AM, Mart Raudsepp wrote: > Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich Mueller: >>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote: >> >>>> Have you asked Debian why they are doing that? >> >>> I did find out but had since forgotten. Here it is: >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10 >> >> So they are aware of the issue since 10 years, but chose not to fix >> it? Seriously, there's no good reason to dance to their tune then. > > It's not to dance to Debians tune, it's to dance to Valve tunes, which > happens to create its runtimes from Ubuntu packages. > I strongly believe that it's important to have such a use case as Steam > work problem-free in Gentoo. It's currently too messy, with and without > using steam runtime. > In the former case (using steam runtime), there are incompatibilities > between libraries found in the steam runtime, and those that it doesn't > include and assumes the system provides (primarily mesa and deps); each > steam runtime version you get to hack around things by removing a small > selection of libraries from the steam runtime dir to get stuff working; > a 1-2 month old upgrade I haven't even managed to get to work yet on a > more up to date machine. > In the latter case (forcing to not use steam runtime), it's near > impossible right now to get a set of 32bit binaries to satisfy even > steam client itself without lots of trial and error, let alone some > 32bit game. > >>> I'm fine with putting it in libpcre-debian package as kentnl >>> suggested. >> >> I still think that the libpcre.so.3 compatibility link shouldn't be >> installed in a generally visible location. Install it in a specific >> directory instead, and start your binary with a wrapper which will >> add that directory to LD_LIBRARY_PATH. > > Isn't this a use case for ldscripts, e.g like gen_usr_ldscript > toolchain.eclass function does, except for pointing libpcre.so.3 to > libpcre.so.1 (so can't use that eclass function, but could just pre- > create one to $FILESDIR if it works)? > The important points should be: > 1) No compilation/linking done on Gentoo should possibly end up with > putting libpcre.so.3 in its DT_NEEDED > 2) libpcre.so should link to libpcre.so.1 > > If we can satisfy these, I don't see a reason to mess around with some > extra package. > Debian reasoning of having stuck with libpcre.so.3 historically is > sound as well, especially if upstream will never use that, given > libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, and > given debians todays situation with this, I would also technically > choose not to change this, as things should migrate over to PCRE2. > > > Mart >
Wouldn't the most simple solution here would be to make a symlink for libpcre.so.3 within the local bindir for each Valve or whatever package that needs it? This is a binary-package-supporting hack, might as well do it in the binary packages that need it. You might still need to wrap the binary to set some environment stuff, not sure; either way it doesn't seem to make sense to make this a system-wide thing.
signature.asc
Description: OpenPGP digital signature
