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 3A08D13832E for ; Thu, 11 Aug 2016 20:07:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EE1E821C097; Thu, 11 Aug 2016 20:07:37 +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 D1A2521C04E for ; Thu, 11 Aug 2016 20:07:36 +0000 (UTC) Received: from [192.168.1.130] (CPE002401f30b73-CM7cb21bc3014a.cpe.net.cable.rogers.com [174.116.156.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id EFA03340C42 for ; Thu, 11 Aug 2016 20:07:34 +0000 (UTC) Subject: Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian To: gentoo-dev@lists.gentoo.org References: <20160811001053.5b98e44a@symphony.aura-online.co.uk> <22444.18637.297626.134016@a1i15.kph.uni-mainz.de> <20160811111141.16bdfcd5@red.yakaraplc.local> <22444.22978.952581.582549@a1i15.kph.uni-mainz.de> <1470927479.5563.16.camel@gentoo.org> <4b09dfc4-b6ca-fb1b-adc3-e9c9da766a10@gentoo.org> <20160811205620.6b782217@symphony.aura-online.co.uk> From: Ian Stakenvicius Message-ID: Date: Thu, 11 Aug 2016 16:07:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 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 In-Reply-To: <20160811205620.6b782217@symphony.aura-online.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5reGHcXURdHkQqdei4qAUFedG8p6Af8Rh" X-Archives-Salt: 6721f61d-84a7-4438-baf6-3771ec50720d X-Archives-Hash: 680268717f062c89c7fbae20516b7f6a This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5reGHcXURdHkQqdei4qAUFedG8p6Af8Rh Content-Type: multipart/mixed; boundary="0EUTTn8bCGgk7J8RNj8CHrQKngoTo06Rl" From: Ian Stakenvicius To: gentoo-dev@lists.gentoo.org Message-ID: Subject: Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian References: <20160811001053.5b98e44a@symphony.aura-online.co.uk> <22444.18637.297626.134016@a1i15.kph.uni-mainz.de> <20160811111141.16bdfcd5@red.yakaraplc.local> <22444.22978.952581.582549@a1i15.kph.uni-mainz.de> <1470927479.5563.16.camel@gentoo.org> <4b09dfc4-b6ca-fb1b-adc3-e9c9da766a10@gentoo.org> <20160811205620.6b782217@symphony.aura-online.co.uk> In-Reply-To: <20160811205620.6b782217@symphony.aura-online.co.uk> --0EUTTn8bCGgk7J8RNj8CHrQKngoTo06Rl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/08/16 03:56 PM, James Le Cuirot wrote: > On Thu, 11 Aug 2016 11:05:00 -0400 > Ian Stakenvicius wrote: >=20 >> On 11/08/16 10:57 AM, Mart Raudsepp wrote: >>> =C3=9Chel kenal p=C3=A4eval, N, 11.08.2016 kell 12:56, kirjutas Ulric= h >>> Mueller: =20 >>>>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote: =20 >>>> =20 >>>>>> Have you asked Debian why they are doing that? =20 >>>> =20 >>>>> I did find out but had since forgotten. Here it is: >>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D380725#10 =20 >>>> >>>> So they are aware of the issue since 10 years, but chose not to fix >>>> it? Seriously, there's no good reason to dance to their tune >>>> then. =20 >>> >>> It's not to dance to Debians tune, it's to dance to Valve tunes, >>> which happens to create its runtimes from Ubuntu packages. >>> I strongly believe that it's important to have such a use case as >>> Steam work problem-free in Gentoo. It's currently too messy, with >>> and without using steam runtime. >>> In the former case (using steam runtime), there are >>> incompatibilities between libraries found in the steam runtime, and >>> those that it doesn't include and assumes the system provides >>> (primarily mesa and deps); each steam runtime version you get to >>> hack around things by removing a small selection of libraries from >>> the steam runtime dir to get stuff working; a 1-2 month old upgrade >>> I haven't even managed to get to work yet on a more up to date >>> machine. In the latter case (forcing to not use steam runtime), >>> it's near impossible right now to get a set of 32bit binaries to >>> satisfy even steam client itself without lots of trial and error, >>> let alone some 32bit game. >>> =20 >>>>> I'm fine with putting it in libpcre-debian package as kentnl >>>>> suggested. =20 >>>> >>>> I still think that the libpcre.so.3 compatibility link shouldn't be >>>> installed in a generally visible location. Install it in a specific >>>> directory instead, and start your binary with a wrapper which will >>>> add that directory to LD_LIBRARY_PATH. =20 >>> >>> Isn't this a use case for ldscripts, e.g like gen_usr_ldscript >>> toolchain.eclass function does, except for pointing libpcre.so.3 to >>> libpcre.so.1 (so can't use that eclass function, but could just pre- >>> create one to $FILESDIR if it works)? >>> The important points should be: >>> 1) No compilation/linking done on Gentoo should possibly end up with >>> putting libpcre.so.3 in its DT_NEEDED >>> 2) libpcre.so should link to libpcre.so.1 >>> >>> If we can satisfy these, I don't see a reason to mess around with >>> some extra package. >>> Debian reasoning of having stuck with libpcre.so.3 historically is >>> sound as well, especially if upstream will never use that, given >>> libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, >>> and given debians todays situation with this, I would also >>> technically choose not to change this, as things should migrate >>> over to PCRE2. >>> >>> Mart >> >> Wouldn't the most simple solution here would be to make a symlink for >> libpcre.so.3 within the local bindir for each Valve or whatever >> package that needs it? This is a binary-package-supporting hack, >> might as well do it in the binary packages that need it. You might >> still need to wrap the binary to set some environment stuff, not sure;= >> either way it doesn't seem to make sense to make this a system-wide >> thing. >=20 > We don't package Steam itself and doing so isn't viable. We package > upstream's script for bootstrapping it under the user's HOME. As such, > there is nowhere to create such a symlink. It's not actually Steam > itself that requires libpcre.so.3 but (at least) one of its games. You > similarly can't create a symlink for each game because they also get > installed under HOME or some other user-defined location. >=20 > I have summed up the feedback. I have also considered that we don't > install the likes of libpng12.so.0 to a different location, even though= > this is also there solely to satisfy pre-compiled binaries. We don't > even have a separate package for that though I will gladly compromise > on that point in this case. With all that in mind, I am going to > install to /lib using a libpcre-debian package. Sorry if you disagree > but since when do we all agree on anything? :) >=20 > Regards, >=20 The non-zero slotted libpng is different -- this is a compiled libpng library that is provided to support binary packages as it the api and abi has changed in newer ones. A symlink of an identical library to address a -name- change is totally different imo. That said, I understand based on what's been described above how this would be more easily handled at the system level rather than at an individual package level (though I expect I would personally still patch the upstream bootstrap script instead) Installing the script to /lib though does not seem like the right way to handle this; i know it works, but realistically this should be installed to /usr/$(get_libdir)/debiancompat/ or similar, and if you still don't want to wrap the apps that need it then also install an /etc/env.d/ file to add this dir to the LDPATH. --0EUTTn8bCGgk7J8RNj8CHrQKngoTo06Rl-- --5reGHcXURdHkQqdei4qAUFedG8p6Af8Rh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAles2wQACgkQ2ugaI38ACPA+jQEArtDg36DcvKaXTkTMMMuQ1xJa 3gUCKbTl+kCJzV8YPx0A/igMeMjs0/zbDh1cwV30xkbflrliNpHI5H4WQmAYQqpL =Dzi/ -----END PGP SIGNATURE----- --5reGHcXURdHkQqdei4qAUFedG8p6Af8Rh--