| 1 |
On 08/10/2016 10:53 PM, Kent Fredric 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 |
Bam, +1 from me. It technically adds package "bloat", but Steam already |
| 64 |
requires a lot of finagling. Requiring a package that's explicitly |
| 65 |
designed to mimic Debian makes it easier to figure out what's wrong, |
| 66 |
should any bugs crop up. |
| 67 |
|
| 68 |
-- |
| 69 |
Daniel Campbell - Gentoo Developer |
| 70 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
| 71 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
Archives