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