1 |
On 11/08/16 03:56 PM, James Le Cuirot wrote: |
2 |
> On Thu, 11 Aug 2016 11:05:00 -0400 |
3 |
> Ian Stakenvicius <axs@g.o> wrote: |
4 |
> |
5 |
>> On 11/08/16 10:57 AM, Mart Raudsepp wrote: |
6 |
>>> Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich |
7 |
>>> Mueller: |
8 |
>>>>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote: |
9 |
>>>> |
10 |
>>>>>> Have you asked Debian why they are doing that? |
11 |
>>>> |
12 |
>>>>> I did find out but had since forgotten. Here it is: |
13 |
>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10 |
14 |
>>>> |
15 |
>>>> So they are aware of the issue since 10 years, but chose not to fix |
16 |
>>>> it? Seriously, there's no good reason to dance to their tune |
17 |
>>>> then. |
18 |
>>> |
19 |
>>> It's not to dance to Debians tune, it's to dance to Valve tunes, |
20 |
>>> which happens to create its runtimes from Ubuntu packages. |
21 |
>>> I strongly believe that it's important to have such a use case as |
22 |
>>> Steam work problem-free in Gentoo. It's currently too messy, with |
23 |
>>> and without using steam runtime. |
24 |
>>> In the former case (using steam runtime), there are |
25 |
>>> incompatibilities between libraries found in the steam runtime, and |
26 |
>>> those that it doesn't include and assumes the system provides |
27 |
>>> (primarily mesa and deps); each steam runtime version you get to |
28 |
>>> hack around things by removing a small selection of libraries from |
29 |
>>> the steam runtime dir to get stuff working; a 1-2 month old upgrade |
30 |
>>> I haven't even managed to get to work yet on a more up to date |
31 |
>>> machine. In the latter case (forcing to not use steam runtime), |
32 |
>>> it's near impossible right now to get a set of 32bit binaries to |
33 |
>>> satisfy even steam client itself without lots of trial and error, |
34 |
>>> let alone some 32bit game. |
35 |
>>> |
36 |
>>>>> I'm fine with putting it in libpcre-debian package as kentnl |
37 |
>>>>> suggested. |
38 |
>>>> |
39 |
>>>> I still think that the libpcre.so.3 compatibility link shouldn't be |
40 |
>>>> installed in a generally visible location. Install it in a specific |
41 |
>>>> directory instead, and start your binary with a wrapper which will |
42 |
>>>> add that directory to LD_LIBRARY_PATH. |
43 |
>>> |
44 |
>>> Isn't this a use case for ldscripts, e.g like gen_usr_ldscript |
45 |
>>> toolchain.eclass function does, except for pointing libpcre.so.3 to |
46 |
>>> libpcre.so.1 (so can't use that eclass function, but could just pre- |
47 |
>>> create one to $FILESDIR if it works)? |
48 |
>>> The important points should be: |
49 |
>>> 1) No compilation/linking done on Gentoo should possibly end up with |
50 |
>>> putting libpcre.so.3 in its DT_NEEDED |
51 |
>>> 2) libpcre.so should link to libpcre.so.1 |
52 |
>>> |
53 |
>>> If we can satisfy these, I don't see a reason to mess around with |
54 |
>>> some extra package. |
55 |
>>> Debian reasoning of having stuck with libpcre.so.3 historically is |
56 |
>>> sound as well, especially if upstream will never use that, given |
57 |
>>> libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, |
58 |
>>> and given debians todays situation with this, I would also |
59 |
>>> technically choose not to change this, as things should migrate |
60 |
>>> over to PCRE2. |
61 |
>>> |
62 |
>>> Mart |
63 |
>> |
64 |
>> Wouldn't the most simple solution here would be to make a symlink for |
65 |
>> libpcre.so.3 within the local bindir for each Valve or whatever |
66 |
>> package that needs it? This is a binary-package-supporting hack, |
67 |
>> might as well do it in the binary packages that need it. You might |
68 |
>> still need to wrap the binary to set some environment stuff, not sure; |
69 |
>> either way it doesn't seem to make sense to make this a system-wide |
70 |
>> thing. |
71 |
> |
72 |
> We don't package Steam itself and doing so isn't viable. We package |
73 |
> upstream's script for bootstrapping it under the user's HOME. As such, |
74 |
> there is nowhere to create such a symlink. It's not actually Steam |
75 |
> itself that requires libpcre.so.3 but (at least) one of its games. You |
76 |
> similarly can't create a symlink for each game because they also get |
77 |
> installed under HOME or some other user-defined location. |
78 |
> |
79 |
> I have summed up the feedback. I have also considered that we don't |
80 |
> install the likes of libpng12.so.0 to a different location, even though |
81 |
> this is also there solely to satisfy pre-compiled binaries. We don't |
82 |
> even have a separate package for that though I will gladly compromise |
83 |
> on that point in this case. With all that in mind, I am going to |
84 |
> install to /lib using a libpcre-debian package. Sorry if you disagree |
85 |
> but since when do we all agree on anything? :) |
86 |
> |
87 |
> Regards, |
88 |
> |
89 |
|
90 |
The non-zero slotted libpng is different -- this is a compiled libpng |
91 |
library that is provided to support binary packages as it the api and |
92 |
abi has changed in newer ones. A symlink of an identical library to |
93 |
address a -name- change is totally different imo. |
94 |
|
95 |
That said, I understand based on what's been described above how this |
96 |
would be more easily handled at the system level rather than at an |
97 |
individual package level (though I expect I would personally still |
98 |
patch the upstream bootstrap script instead) |
99 |
|
100 |
Installing the script to /lib though does not seem like the right way |
101 |
to handle this; i know it works, but realistically this should be |
102 |
installed to /usr/$(get_libdir)/debiancompat/ or similar, and if you |
103 |
still don't want to wrap the apps that need it then also install an |
104 |
/etc/env.d/ file to add this dir to the LDPATH. |