Gentoo Archives: gentoo-dev

From: Mike Gilbert <floppym@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian
Date: Thu, 11 Aug 2016 15:41:49
Message-Id: CAJ0EP40SHvK-N=_ewVaEMQOo6wZscoatAwzKwG955wV+yPfV1g@mail.gmail.com
In Reply to: Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian by Kent Fredric
1 On Thu, Aug 11, 2016 at 1:53 AM, Kent Fredric <kentnl@g.o> wrote:
2 > On Thu, 11 Aug 2016 00:10:53 +0100
3 > James Le Cuirot <chewi@g.o> wrote:
4 >
5 >> Hello all,
6 >>
7 >> We, like almost everyone else and presumably upstream, install PCRE 8
8 >> as libpcre.so.1. Debian, for reasons best known to themselves, install
9 >> it as libpcre.so.3. With Ubuntu still being the most widely accepted
10 >> "standard" Linux desktop, this presents a problem when dealing with
11 >> pre-compiled binaries.
12 >>
13 >> I have been working on a script to replace the rather lacking
14 >> steam-games-meta ebuild (see steam-overlay). I'm very excited about
15 >> releasing it soon as I think it is a major step forwards in our
16 >> ability to easily run Steam without the official Ubuntu-based runtime.
17 >>
18 >> Before I put it out there, I'd like to get Alien Isolation working
19 >> properly. It links to libpcre.so.3. Hacking the binary might work but
20 >> this isn't ideal and not always an option as some games use Valve's
21 >> anti-cheat system, which is ruthless.
22 >>
23 >> I have found that creating a symlink in /usr/lib that points
24 >> to /lib/libpcre.so.1 works, except that when you run ldconfig, it
25 >> automatically creates another symlink from /usr/lib/libpcre.so.1 to
26 >> libpcre.so.3. If you create the first symlink in /lib instead then the
27 >> existing /lib/libpcre.so.1 holds after running ldconfig. The latter
28 >> location is therefore probably preferable.
29 >>
30 >> Would anyone have any issue with adding this to our libpcre package? I
31 >> don't foresee any problems. libpcre.so would obviously still point to
32 >> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
33 >> as upstream have released PCRE2 as libpcre2, effectively an entirely
34 >> separate library.
35 >>
36 >> I could create a Steam-specific package for this but that would mean
37 >> adding some additional Steam-specific location to ld.so.conf, which
38 >> I'm trying to avoid. It would be nice to solve this generally anyway.
39 >>
40 >> Thoughts?
41 >>
42 >
43 > I'd say this is the sort of thing that has more application than just
44 > steam.
45 >
46 > I'd just suggest a libpcre-debian package, which provides the .so via
47 > symlink and dependency mechanisms.
48 >
49 > That way *if* anything happens in the future, we can just introduce
50 > blockers in the right place.
51 >
52 > Then the applicable stuff depends on libpcre-debian for the forseeable
53 > future.
54 >
55 > And this way, if debian do anything else magical, we can probably copy
56 > them and build a libpcre like they do for interop.
57 >
58 > Essentially, the point here is to see debians libpcre is a competing
59 > implementation, even though we can locally pretend they're not at the
60 > technical level, it works as " conceptual model " for the problem we
61 > have.
62 >
63
64 Just here to add a +1 to this idea.