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