Gentoo Archives: gentoo-portage-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] New preserve-libs feature
Date: Sat, 17 Feb 2007 16:39:54
Message-Id: 200702171139.44920.vapier@gentoo.org
In Reply to: Re: [gentoo-portage-dev] New preserve-libs feature by Brian Harring
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