From: Ian Stakenvicius <axs@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian
Date: Thu, 11 Aug 2016 11:05:00 -0400 [thread overview]
Message-ID: <4b09dfc4-b6ca-fb1b-adc3-e9c9da766a10@gentoo.org> (raw)
In-Reply-To: <1470927479.5563.16.camel@gentoo.org>
[-- Attachment #1.1: Type: text/plain, Size: 3203 bytes --]
On 11/08/16 10:57 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich Mueller:
>>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:
>>
>>>> Have you asked Debian why they are doing that?
>>
>>> I did find out but had since forgotten. Here it is:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10
>>
>> 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.
>
> 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.
>
>>> I'm fine with putting it in libpcre-debian package as kentnl
>>> suggested.
>>
>> 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.
>
> 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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
next prev parent reply other threads:[~2016-08-11 15:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-10 23:10 [gentoo-dev] libpcre.so.3 - Compatibility with Debian James Le Cuirot
2016-08-11 5:53 ` Kent Fredric
2016-08-11 15:41 ` Mike Gilbert
2016-08-11 18:57 ` Patrick McLean
2016-08-18 5:45 ` Daniel Campbell
2016-08-11 9:43 ` Ulrich Mueller
2016-08-11 10:11 ` James Le Cuirot
2016-08-11 10:56 ` Ulrich Mueller
2016-08-11 11:20 ` James Le Cuirot
2016-08-11 11:49 ` Kristian Fiskerstrand
2016-08-11 12:04 ` Ulrich Mueller
2016-08-11 12:13 ` Rich Freeman
2016-08-11 14:57 ` Mart Raudsepp
2016-08-11 15:03 ` Ciaran McCreesh
2016-08-11 15:05 ` Ian Stakenvicius [this message]
2016-08-11 15:15 ` Mart Raudsepp
2016-08-11 19:56 ` James Le Cuirot
2016-08-11 20:07 ` Ian Stakenvicius
2016-08-11 21:34 ` Kent Fredric
2016-08-11 22:00 ` Mike Gilbert
2016-08-12 1:19 ` Mart Raudsepp
2016-08-18 6:06 ` Daniel Campbell
2016-08-11 20:50 ` Michał Górny
2016-08-11 21:30 ` James Le Cuirot
2016-08-11 21:55 ` Mike Gilbert
2016-08-12 0:27 ` Patrick McLean
2016-08-12 0:32 ` Kent Fredric
2016-08-12 14:12 ` james
2016-08-12 15:39 ` Kent Fredric
2016-08-12 17:40 ` james
2016-08-12 17:48 ` M. J. Everitt
2016-08-12 22:36 ` Rich Freeman
2016-08-12 17:55 ` Kent Fredric
2016-08-11 16:23 ` james
2016-08-11 16:32 ` Mart Raudsepp
2026-08-13 18:27 ` james
2016-08-11 18:02 ` Matt Turner
2016-08-11 18:27 ` Deven Lahoti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b09dfc4-b6ca-fb1b-adc3-e9c9da766a10@gentoo.org \
--to=axs@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox