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

[Patrick McLean <chutzpah@gentoo.org>]

On Thu, 11 Aug 2016 17:53:31 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> 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.
> 

This sounds reasonable to me, that way we have pseudo-universal
handling of this for everything that needs it. The people who object to
adding stuff to support binary packages can just not install the
libpcre-debian package.