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