On Thu, 11 Aug 2016 11:43:41 +0200 Ulrich Mueller <u...@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
