On Thu, 11 Aug 2016 00:10:53 +0100
James Le Cuirot <chewi@gentoo.org> wrote:

> Hello all,
> 
> We, like almost everyone else and presumably upstream, install PCRE 8
> as libpcre.so.1. Debian, for reasons best known to themselves, install
> it as libpcre.so.3. With Ubuntu still being the most widely accepted
> "standard" Linux desktop, this presents a problem when dealing with
> pre-compiled binaries.
> 
> I have been working on a script to replace the rather lacking
> steam-games-meta ebuild (see steam-overlay). I'm very excited about
> releasing it soon as I think it is a major step forwards in our
> ability to easily run Steam without the official Ubuntu-based runtime.
> 
> Before I put it out there, I'd like to get Alien Isolation working
> properly. It links to libpcre.so.3. Hacking the binary might work but
> this isn't ideal and not always an option as some games use Valve's
> anti-cheat system, which is ruthless.
> 
> I have found that creating a symlink in /usr/lib that points
> to /lib/libpcre.so.1 works, except that when you run ldconfig, it
> automatically creates another symlink from /usr/lib/libpcre.so.1 to
> libpcre.so.3. If you create the first symlink in /lib instead then the
> existing /lib/libpcre.so.1 holds after running ldconfig. The latter
> location is therefore probably preferable.
> 
> Would anyone have any issue with adding this to our libpcre package? I
> don't foresee any problems. libpcre.so would obviously still point to
> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
> as upstream have released PCRE2 as libpcre2, effectively an entirely
> separate library.
> 
> I could create a Steam-specific package for this but that would mean
> adding some additional Steam-specific location to ld.so.conf, which
> I'm trying to avoid. It would be nice to solve this generally anyway.
> 
> Thoughts?
> 

I'd say this is the sort of thing that has more application than just
steam.

I'd just suggest a libpcre-debian package, which provides the .so via
symlink and dependency mechanisms.

That way *if* anything happens in the future, we can just introduce
blockers in the right place.

Then the applicable stuff depends on libpcre-debian for the forseeable
future.

And this way, if debian do anything else magical, we can probably copy
them and build a libpcre like they do for interop.

Essentially, the point here is to see debians libpcre is a competing
implementation, even though we can locally pretend they're not at the
technical level, it works as " conceptual model " for the problem we
have.