| 1 |
Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich Mueller: |
| 2 |
> > > > > > On Thu, 11 Aug 2016, James Le Cuirot wrote: |
| 3 |
> |
| 4 |
> > > Have you asked Debian why they are doing that? |
| 5 |
> |
| 6 |
> > I did find out but had since forgotten. Here it is: |
| 7 |
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10 |
| 8 |
> |
| 9 |
> So they are aware of the issue since 10 years, but chose not to fix |
| 10 |
> it? Seriously, there's no good reason to dance to their tune then. |
| 11 |
|
| 12 |
It's not to dance to Debians tune, it's to dance to Valve tunes, which |
| 13 |
happens to create its runtimes from Ubuntu packages. |
| 14 |
I strongly believe that it's important to have such a use case as Steam |
| 15 |
work problem-free in Gentoo. It's currently too messy, with and without |
| 16 |
using steam runtime. |
| 17 |
In the former case (using steam runtime), there are incompatibilities |
| 18 |
between libraries found in the steam runtime, and those that it doesn't |
| 19 |
include and assumes the system provides (primarily mesa and deps); each |
| 20 |
steam runtime version you get to hack around things by removing a small |
| 21 |
selection of libraries from the steam runtime dir to get stuff working; |
| 22 |
a 1-2 month old upgrade I haven't even managed to get to work yet on a |
| 23 |
more up to date machine. |
| 24 |
In the latter case (forcing to not use steam runtime), it's near |
| 25 |
impossible right now to get a set of 32bit binaries to satisfy even |
| 26 |
steam client itself without lots of trial and error, let alone some |
| 27 |
32bit game. |
| 28 |
|
| 29 |
> > I'm fine with putting it in libpcre-debian package as kentnl |
| 30 |
> > suggested. |
| 31 |
> |
| 32 |
> I still think that the libpcre.so.3 compatibility link shouldn't be |
| 33 |
> installed in a generally visible location. Install it in a specific |
| 34 |
> directory instead, and start your binary with a wrapper which will |
| 35 |
> add that directory to LD_LIBRARY_PATH. |
| 36 |
|
| 37 |
Isn't this a use case for ldscripts, e.g like gen_usr_ldscript |
| 38 |
toolchain.eclass function does, except for pointing libpcre.so.3 to |
| 39 |
libpcre.so.1 (so can't use that eclass function, but could just pre- |
| 40 |
create one to $FILESDIR if it works)? |
| 41 |
The important points should be: |
| 42 |
1) No compilation/linking done on Gentoo should possibly end up with |
| 43 |
putting libpcre.so.3 in its DT_NEEDED |
| 44 |
2) libpcre.so should link to libpcre.so.1 |
| 45 |
|
| 46 |
If we can satisfy these, I don't see a reason to mess around with some |
| 47 |
extra package. |
| 48 |
Debian reasoning of having stuck with libpcre.so.3 historically is |
| 49 |
sound as well, especially if upstream will never use that, given |
| 50 |
libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, and |
| 51 |
given debians todays situation with this, I would also technically |
| 52 |
choose not to change this, as things should migrate over to PCRE2. |
| 53 |
|
| 54 |
|
| 55 |
Mart |
Archives