1 |
On Thu, 11 Aug 2016 20:56:20 +0100 |
2 |
James Le Cuirot <chewi@g.o> wrote: |
3 |
|
4 |
> On Thu, 11 Aug 2016 11:05:00 -0400 |
5 |
> Ian Stakenvicius <axs@g.o> wrote: |
6 |
> |
7 |
> > On 11/08/16 10:57 AM, Mart Raudsepp wrote: |
8 |
> > > Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich |
9 |
> > > Mueller: |
10 |
> > >>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote: |
11 |
> > >> |
12 |
> > >>>> Have you asked Debian why they are doing that? |
13 |
> > >> |
14 |
> > >>> I did find out but had since forgotten. Here it is: |
15 |
> > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10 |
16 |
> > >> |
17 |
> > >> So they are aware of the issue since 10 years, but chose not to fix |
18 |
> > >> it? Seriously, there's no good reason to dance to their tune |
19 |
> > >> then. |
20 |
> > > |
21 |
> > > It's not to dance to Debians tune, it's to dance to Valve tunes, |
22 |
> > > which happens to create its runtimes from Ubuntu packages. |
23 |
> > > I strongly believe that it's important to have such a use case as |
24 |
> > > Steam work problem-free in Gentoo. It's currently too messy, with |
25 |
> > > and without using steam runtime. |
26 |
> > > In the former case (using steam runtime), there are |
27 |
> > > incompatibilities between libraries found in the steam runtime, and |
28 |
> > > those that it doesn't include and assumes the system provides |
29 |
> > > (primarily mesa and deps); each steam runtime version you get to |
30 |
> > > hack around things by removing a small selection of libraries from |
31 |
> > > the steam runtime dir to get stuff working; a 1-2 month old upgrade |
32 |
> > > I haven't even managed to get to work yet on a more up to date |
33 |
> > > machine. In the latter case (forcing to not use steam runtime), |
34 |
> > > it's near impossible right now to get a set of 32bit binaries to |
35 |
> > > satisfy even steam client itself without lots of trial and error, |
36 |
> > > let alone some 32bit game. |
37 |
> > > |
38 |
> > >>> I'm fine with putting it in libpcre-debian package as kentnl |
39 |
> > >>> suggested. |
40 |
> > >> |
41 |
> > >> I still think that the libpcre.so.3 compatibility link shouldn't be |
42 |
> > >> installed in a generally visible location. Install it in a specific |
43 |
> > >> directory instead, and start your binary with a wrapper which will |
44 |
> > >> add that directory to LD_LIBRARY_PATH. |
45 |
> > > |
46 |
> > > Isn't this a use case for ldscripts, e.g like gen_usr_ldscript |
47 |
> > > toolchain.eclass function does, except for pointing libpcre.so.3 to |
48 |
> > > libpcre.so.1 (so can't use that eclass function, but could just pre- |
49 |
> > > create one to $FILESDIR if it works)? |
50 |
> > > The important points should be: |
51 |
> > > 1) No compilation/linking done on Gentoo should possibly end up with |
52 |
> > > putting libpcre.so.3 in its DT_NEEDED |
53 |
> > > 2) libpcre.so should link to libpcre.so.1 |
54 |
> > > |
55 |
> > > If we can satisfy these, I don't see a reason to mess around with |
56 |
> > > some extra package. |
57 |
> > > Debian reasoning of having stuck with libpcre.so.3 historically is |
58 |
> > > sound as well, especially if upstream will never use that, given |
59 |
> > > libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, |
60 |
> > > and given debians todays situation with this, I would also |
61 |
> > > technically choose not to change this, as things should migrate |
62 |
> > > over to PCRE2. |
63 |
> > > |
64 |
> > > Mart |
65 |
> > |
66 |
> > Wouldn't the most simple solution here would be to make a symlink for |
67 |
> > libpcre.so.3 within the local bindir for each Valve or whatever |
68 |
> > package that needs it? This is a binary-package-supporting hack, |
69 |
> > might as well do it in the binary packages that need it. You might |
70 |
> > still need to wrap the binary to set some environment stuff, not sure; |
71 |
> > either way it doesn't seem to make sense to make this a system-wide |
72 |
> > thing. |
73 |
> |
74 |
> We don't package Steam itself and doing so isn't viable. We package |
75 |
> upstream's script for bootstrapping it under the user's HOME. As such, |
76 |
> there is nowhere to create such a symlink. It's not actually Steam |
77 |
> itself that requires libpcre.so.3 but (at least) one of its games. You |
78 |
> similarly can't create a symlink for each game because they also get |
79 |
> installed under HOME or some other user-defined location. |
80 |
|
81 |
Well, how about you package a script to easily install Ubuntu on top of |
82 |
Gentoo? That should make your system much more compliant with Valve's |
83 |
idiocy than random symlinks. |
84 |
|
85 |
> I have summed up the feedback. I have also considered that we don't |
86 |
> install the likes of libpng12.so.0 to a different location, even though |
87 |
> this is also there solely to satisfy pre-compiled binaries. We don't |
88 |
> even have a separate package for that though I will gladly compromise |
89 |
> on that point in this case. With all that in mind, I am going to |
90 |
> install to /lib using a libpcre-debian package. Sorry if you disagree |
91 |
> but since when do we all agree on anything? :) |
92 |
|
93 |
libpng12.so.0 is an old version of a normal upstream library. It has |
94 |
been released with that SONAME upstream, and it is globally meaningful. |
95 |
libpcre.so.3 is some crappy Debian invention that's causing total |
96 |
mayhem. It's not globally meaningful, it can collide with a future |
97 |
upstream version and it messes up .so symlinks, as you already noticed. |
98 |
|
99 |
If you are going to commit such crap into Gentoo ignoring people more |
100 |
knowledgeable than you, please spare us the effort and open a QA bug |
101 |
against it requesting that you remove it immediately. Thank you. Feel |
102 |
free to also request revoking your commit rights for explicit ignoring |
103 |
of QA feedback. |
104 |
|
105 |
Now, seriously: Steam is a total pile of crap. We already had to hack |
106 |
it to work-around completely braindead LD_LIBRARY_PATH override idiocy. |
107 |
I don't see how much of a problem would it be to add an additional path |
108 |
with crappy symlinks for it without polluting the whole system with |
109 |
crap. |
110 |
|
111 |
-- |
112 |
Best regards, |
113 |
Michał Górny |
114 |
<http://dev.gentoo.org/~mgorny/> |