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 16:07:27 -0400 [thread overview]
Message-ID: <e36b1a54-ddb7-8b70-7a0d-d234d0c1b05b@gentoo.org> (raw)
In-Reply-To: <20160811205620.6b782217@symphony.aura-online.co.uk>
[-- Attachment #1.1: Type: text/plain, Size: 5272 bytes --]
On 11/08/16 03:56 PM, James Le Cuirot wrote:
> On Thu, 11 Aug 2016 11:05:00 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
>
>> 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.
>
> 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.
>
> 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? :)
>
> Regards,
>
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
next prev parent reply other threads:[~2016-08-11 20:07 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
2016-08-11 15:15 ` Mart Raudsepp
2016-08-11 19:56 ` James Le Cuirot
2016-08-11 20:07 ` Ian Stakenvicius [this message]
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=e36b1a54-ddb7-8b70-7a0d-d234d0c1b05b@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