1 |
On Thu, 11 Aug 2016 11:43:41 +0200 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> >>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote: |
5 |
> |
6 |
> > We, like almost everyone else and presumably upstream, install PCRE |
7 |
> > 8 as libpcre.so.1. Debian, for reasons best known to themselves, |
8 |
> > install it as libpcre.so.3. With Ubuntu still being the most widely |
9 |
> > accepted "standard" Linux desktop, this presents a problem when |
10 |
> > dealing with pre-compiled binaries. |
11 |
> |
12 |
> Have you asked Debian why they are doing that? |
13 |
|
14 |
I did find out but had since forgotten. Here it is: |
15 |
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10 |
16 |
|
17 |
On that basis, this is a safe thing to do. They are indeed the same |
18 |
version and there is no incompatibility. |
19 |
|
20 |
> > [...] |
21 |
> |
22 |
> > I have found that creating a symlink in /usr/lib that points |
23 |
> > to /lib/libpcre.so.1 works, except that when you run ldconfig, it |
24 |
> > automatically creates another symlink from /usr/lib/libpcre.so.1 to |
25 |
> > libpcre.so.3. If you create the first symlink in /lib instead then |
26 |
> > the existing /lib/libpcre.so.1 holds after running ldconfig. The |
27 |
> > latter location is therefore probably preferable. |
28 |
> |
29 |
> > Would anyone have any issue with adding this to our libpcre |
30 |
> > package? I don't foresee any problems. libpcre.so would obviously |
31 |
> > still point to libpcre.so.1. I'm pretty sure there will never be |
32 |
> > another libpcre.so.3 as upstream have released PCRE2 as libpcre2, |
33 |
> > effectively an entirely separate library. |
34 |
> |
35 |
> This looks like a bad hack. As you said above, it will confuse |
36 |
> ldconfig, unless some trickery with /lib vs /usr/lib is used. |
37 |
|
38 |
I wouldn't call it trickery. Here's what happens when you put it |
39 |
in /lib. I can't see anything wrong here? |
40 |
|
41 |
# cd /lib |
42 |
# ls -l libpcre.* |
43 |
lrwxrwxrwx 1 root root 16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7 |
44 |
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7 |
45 |
# ln -s libpcre.so.1 libpcre.so.3 |
46 |
# ls -l libpcre.* |
47 |
lrwxrwxrwx 1 root root 16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7 |
48 |
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7 |
49 |
lrwxrwxrwx 1 root root 12 Aug 11 11:01 libpcre.so.3 -> libpcre.so.1 |
50 |
# ldconfig |
51 |
# ls -l libpcre.* |
52 |
lrwxrwxrwx 1 root root 16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7 |
53 |
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7 |
54 |
lrwxrwxrwx 1 root root 12 Aug 11 11:01 libpcre.so.3 -> libpcre.so.1 |
55 |
|
56 |
> IMHO providing compatibility symlinks for proprietary binary-only |
57 |
> programs isn't the task of the libpcre package. |
58 |
|
59 |
I'm fine with putting it in libpcre-debian package as kentnl suggested. |
60 |
|
61 |
> I remember that long time ago we had a similar issue with motif and |
62 |
> icaclient (motif installing .so.4 but icaclient linking to .so.3). |
63 |
> See: https://bugs.gentoo.org/show_bug.cgi?id=204264#c4 |
64 |
|
65 |
I've read through that and but I don't believe this is falling foul in |
66 |
the same way. The icaclient package should not have installed a |
67 |
potentially conflicting libXm symlink; libpcre-debian would be an |
68 |
appropriate package. It also pointed libXm.so.3 to a different |
69 |
underlying version, which may have caused breakage in other situations; |
70 |
the libpcre symlink would point to the same version. |
71 |
|
72 |
-- |
73 |
James Le Cuirot (chewi) |
74 |
Gentoo Linux Developer |