1 |
>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote: |
2 |
|
3 |
> We, like almost everyone else and presumably upstream, install PCRE 8 |
4 |
> as libpcre.so.1. Debian, for reasons best known to themselves, install |
5 |
> it as libpcre.so.3. With Ubuntu still being the most widely accepted |
6 |
> "standard" Linux desktop, this presents a problem when dealing with |
7 |
> pre-compiled binaries. |
8 |
|
9 |
Have you asked Debian why they are doing that? |
10 |
|
11 |
> [...] |
12 |
|
13 |
> I have found that creating a symlink in /usr/lib that points |
14 |
> to /lib/libpcre.so.1 works, except that when you run ldconfig, it |
15 |
> automatically creates another symlink from /usr/lib/libpcre.so.1 to |
16 |
> libpcre.so.3. If you create the first symlink in /lib instead then the |
17 |
> existing /lib/libpcre.so.1 holds after running ldconfig. The latter |
18 |
> location is therefore probably preferable. |
19 |
|
20 |
> Would anyone have any issue with adding this to our libpcre package? I |
21 |
> don't foresee any problems. libpcre.so would obviously still point to |
22 |
> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3 |
23 |
> as upstream have released PCRE2 as libpcre2, effectively an entirely |
24 |
> separate library. |
25 |
|
26 |
This looks like a bad hack. As you said above, it will confuse |
27 |
ldconfig, unless some trickery with /lib vs /usr/lib is used. |
28 |
|
29 |
IMHO providing compatibility symlinks for proprietary binary-only |
30 |
programs isn't the task of the libpcre package. Patch the binary, or |
31 |
have the depending package create the libpcre.so.3 symlink, but not in |
32 |
/usr/lib or /lib, but in a location specific to that package. |
33 |
|
34 |
I remember that long time ago we had a similar issue with motif and |
35 |
icaclient (motif installing .so.4 but icaclient linking to .so.3). |
36 |
See: https://bugs.gentoo.org/show_bug.cgi?id=204264#c4 |
37 |
|
38 |
Ulrich |