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

[James Le Cuirot <chewi@gentoo.org>]

On Thu, 11 Aug 2016 11:43:41 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> 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 did find out but had since forgotten. Here it is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10

On that basis, this is a safe thing to do. They are indeed the same
version and there is no incompatibility.

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

I wouldn't call it trickery. Here's what happens when you put it
in /lib. I can't see anything wrong here?

# cd /lib
# ls -l libpcre.*
lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
# ln -s libpcre.so.1 libpcre.so.3
# ls -l libpcre.*
lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
lrwxrwxrwx 1 root root     12 Aug 11 11:01 libpcre.so.3 -> libpcre.so.1
# ldconfig
# ls -l libpcre.*
lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
lrwxrwxrwx 1 root root     12 Aug 11 11:01 libpcre.so.3 -> libpcre.so.1

> IMHO providing compatibility symlinks for proprietary binary-only
> programs isn't the task of the libpcre package.

I'm fine with putting it in libpcre-debian package as kentnl suggested.

> 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

I've read through that and but I don't believe this is falling foul in
the same way. The icaclient package should not have installed a
potentially conflicting libXm symlink; libpcre-debian would be an
appropriate package. It also pointed libXm.so.3 to a different
underlying version, which may have caused breakage in other situations;
the libpcre symlink would point to the same version.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer