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