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