Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Ian Stakenvicius]

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.