Ü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
