Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5784 bytes --]

On Thu, 11 Aug 2016 20:56:20 +0100
James Le Cuirot <chewi@gentoo.org> 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.

Well, how about you package a script to easily install Ubuntu on top of
Gentoo? That should make your system much more compliant with Valve's
idiocy than random symlinks.

> 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? :)

libpng12.so.0 is an old version of a normal upstream library. It has
been released with that SONAME upstream, and it is globally meaningful.
libpcre.so.3 is some crappy Debian invention that's causing total
mayhem. It's not globally meaningful, it can collide with a future
upstream version and it messes up .so symlinks, as you already noticed.

If you are going to commit such crap into Gentoo ignoring people more
knowledgeable than you, please spare us the effort and open a QA bug
against it requesting that you remove it immediately. Thank you. Feel
free to also request revoking your commit rights for explicit ignoring
of QA feedback.

Now, seriously: Steam is a total pile of crap. We already had to hack
it to work-around completely braindead LD_LIBRARY_PATH override idiocy.
I don't see how much of a problem would it be to add an additional path
with crappy symlinks for it without polluting the whole system with
crap.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]