1 |
On Saturday 17 February 2007, Brian Harring wrote: |
2 |
> On Sat, Feb 17, 2007 at 10:09:35AM -0500, Mike Frysinger wrote: |
3 |
> > On Saturday 17 February 2007, Brian Harring wrote: |
4 |
> > > (assuming the code knows the appropriate linker args) |
5 |
> > |
6 |
> > there is no such thing ... it's always "-lfoo" |
7 |
> |
8 |
> The point is that it is *not* always -lfoo. Commenting about packages |
9 |
> that collapse, split libs apart, where -lorig becomes -lnew1 -lnew2. |
10 |
|
11 |
so why is this an issue ... the build system for a package either takes it |
12 |
into account or it doesnt, it'll behave exactly the same whether we preserve |
13 |
the ABI lib |
14 |
|
15 |
we're preserving runtime libs here, not ones detectable by a linker process |
16 |
and thus a build system |
17 |
|
18 |
> Also, so help me, if you respond to valid critism with "it doesn't |
19 |
> actually matter" as a retort, you're getting wedgied considering |
20 |
> this is one of the scenarios this patch is supposed to address :p |
21 |
|
22 |
i guess come up with a valid criticism first and then i wont use that |
23 |
|
24 |
> Eh? setuid comes to mind |
25 |
|
26 |
why ? pretty much all LD_* variables are filtered by ldso in a set*id |
27 |
environment |
28 |
|
29 |
> or any other attempt to finagle privs via forcing the bad lib. |
30 |
|
31 |
considering the only privs you can finagle are your own, this is not an issue |
32 |
|
33 |
> Combined with the scenario above (where a |
34 |
> crappy pkg can hold the lib around for a *long* time), tend to think |
35 |
> it matters. |
36 |
|
37 |
it doesnt |
38 |
|
39 |
> It's a change in behaviour; previously, would just flat out stop; now |
40 |
> it'll run, but probably take a poo in your shoes. |
41 |
> |
42 |
> Going from the potential of "it won't run" to "it eats itself in |
43 |
> special way" is *not* something I'd blistfully write off as "not |
44 |
> worth worring over", considering what this change intends to address. |
45 |
|
46 |
let's review the original by copy & paste: |
47 |
- I'm not claiming that it's a silver bullet to all possible runtime |
48 |
linker problems, it's supposed to cover some of the common cases (like |
49 |
the expat problem) |
50 |
|
51 |
what you're talking about can never be fully solved by the methodology |
52 |
utilized here ... if you want the full solution, go implement your own |
53 |
behavior |
54 |
|
55 |
> Additional comment, introducing the change makes it so that glsa's |
56 |
> aren't really as accurate- version based, rather then lib. |
57 |
|
58 |
considering current glsa integration (== 0), i'd say proper general |
59 |
infrastructure needs to be put into place first |
60 |
-mike |