On 08/10/2016 10:53 PM, Kent Fredric wrote: > On Thu, 11 Aug 2016 00:10:53 +0100 > James Le Cuirot <[email protected]> wrote: > >> Hello all, >> >> We, like almost everyone else and presumably upstream, install PCRE 8 >> as libpcre.so.1. Debian, for reasons best known to themselves, install >> it as libpcre.so.3. With Ubuntu still being the most widely accepted >> "standard" Linux desktop, this presents a problem when dealing with >> pre-compiled binaries. >> >> I have been working on a script to replace the rather lacking >> steam-games-meta ebuild (see steam-overlay). I'm very excited about >> releasing it soon as I think it is a major step forwards in our >> ability to easily run Steam without the official Ubuntu-based runtime. >> >> Before I put it out there, I'd like to get Alien Isolation working >> properly. It links to libpcre.so.3. Hacking the binary might work but >> this isn't ideal and not always an option as some games use Valve's >> anti-cheat system, which is ruthless. >> >> I have found that creating a symlink in /usr/lib that points >> to /lib/libpcre.so.1 works, except that when you run ldconfig, it >> automatically creates another symlink from /usr/lib/libpcre.so.1 to >> libpcre.so.3. If you create the first symlink in /lib instead then the >> existing /lib/libpcre.so.1 holds after running ldconfig. The latter >> location is therefore probably preferable. >> >> Would anyone have any issue with adding this to our libpcre package? I >> don't foresee any problems. libpcre.so would obviously still point to >> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3 >> as upstream have released PCRE2 as libpcre2, effectively an entirely >> separate library. >> >> I could create a Steam-specific package for this but that would mean >> adding some additional Steam-specific location to ld.so.conf, which >> I'm trying to avoid. It would be nice to solve this generally anyway. >> >> Thoughts? >> > > I'd say this is the sort of thing that has more application than just > steam. > > I'd just suggest a libpcre-debian package, which provides the .so via > symlink and dependency mechanisms. > > That way *if* anything happens in the future, we can just introduce > blockers in the right place. > > Then the applicable stuff depends on libpcre-debian for the forseeable > future. > > And this way, if debian do anything else magical, we can probably copy > them and build a libpcre like they do for interop. > > Essentially, the point here is to see debians libpcre is a competing > implementation, even though we can locally pretend they're not at the > technical level, it works as " conceptual model " for the problem we > have. > Bam, +1 from me. It technically adds package "bloat", but Steam already requires a lot of finagling. Requiring a package that's explicitly designed to mimic Debian makes it easier to figure out what's wrong, should any bugs crop up.
-- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
