>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:

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

Have you asked Debian why they are doing that?

> [...]

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

This looks like a bad hack. As you said above, it will confuse
ldconfig, unless some trickery with /lib vs /usr/lib is used.

IMHO providing compatibility symlinks for proprietary binary-only
programs isn't the task of the libpcre package. Patch the binary, or
have the depending package create the libpcre.so.3 symlink, but not in
/usr/lib or /lib, but in a location specific to that package.

I remember that long time ago we had a similar issue with motif and
icaclient (motif installing .so.4 but icaclient linking to .so.3).
See: https://bugs.gentoo.org/show_bug.cgi?id=204264#c4

Ulrich