From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B18E213832E for ; Thu, 11 Aug 2016 18:57:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E696B21C20A; Thu, 11 Aug 2016 18:57:34 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0633B21C13A for ; Thu, 11 Aug 2016 18:57:34 +0000 (UTC) Received: from patrickm (unknown [100.42.98.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: chutzpah) by smtp.gentoo.org (Postfix) with ESMTPSA id 07474340AE2; Thu, 11 Aug 2016 18:57:32 +0000 (UTC) Date: Thu, 11 Aug 2016 11:57:18 -0700 From: Patrick McLean To: Kent Fredric Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian Message-ID: <20160811115718.474f475d@patrickm> In-Reply-To: <20160811175331.1ffdef04@katipo2.lan> References: <20160811001053.5b98e44a@symphony.aura-online.co.uk> <20160811175331.1ffdef04@katipo2.lan> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: d2e466b0-536e-4b50-97a4-0afec905a2c9 X-Archives-Hash: d011c3398f85dd1d5e54ed9c4cc992c8 On Thu, 11 Aug 2016 17:53:31 +1200 Kent Fredric wrote: > On Thu, 11 Aug 2016 00:10:53 +0100 > James Le Cuirot 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. > This sounds reasonable to me, that way we have pseudo-universal handling of this for everything that needs it. The people who object to adding stuff to support binary packages can just not install the libpcre-debian package.