On Fri, 2005-06-17 at 09:32 +0100, Andrew Suffield wrote: > On Fri, Jun 17, 2005 at 12:15:25AM -0700, Steve Langasek wrote: > > On Fri, Jun 17, 2005 at 08:07:34AM +0100, Andrew Suffield wrote: > > > On Fri, Jun 17, 2005 at 04:26:36AM +0100, Scott James Remnant wrote: > > > > On Thu, 2005-06-16 at 17:20 -0700, Steve Langasek wrote: > > > > > > > So, maybe it's time to revisit the weaknesses of the shlibs system, > > > > > particularly as they apply to glibc. Scott James Remnant had done some > > > > > poking in this area about a year ago, which involved tracking when > > > > > individual symbols were added to a package -- apparently, many packages > > > > > would actually be happy with glibc 2.1 or so (at least on i386), but we have > > > > > no way to track this... > > > > > > I was just thinking the same with this thread ... > > > > > > The principal problem with the "shlibsyms" stuff was that in order to > > > > track when symbols are added to a package, you need the list of the set > > > > of symbols that were in the last version -- and as the source packages > > > > are put together before the binary, the source package wouldn't contain > > > > the updated set of symbols. > > > > > Once we begin to deploy icheck, we will have all this > > > information. Haven't yet figured out how to do anything with it. > > > > > It is not sufficient to track when symbols are added to a package. You > > > must also check when their meaning changes. I have not yet been able > > > to find a way to do this on a per-symbol basis, only a per-library > > > one (I can find examples that break all the 'obvious' approaches). > > > > However, breaking the meaning of any symbol is supposed to mean that we punt > > by changing the soname, no? > > The notable exception would be glibc, which is the really interesting > case here. > Who are historically pretty well behaved about changing symbol versions if they change the API. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part