On Thu, 11 Aug 2016 11:05:00 -0400 Ian Stakenvicius <a...@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, -- James Le Cuirot (chewi) Gentoo Linux Developer
pgpu6A9fyj5lk.pgp
Description: OpenPGP digital signature
