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. > One "easy" way would be to simply make it an error for there to be any > new symbols while building a source package -- so you'd have to update > the table before building so it gets put into the source; this is a bit > invasive though. http://lists.debian.org/debian-devel/2005/06/msg01185.html >:) Invasive, yes, but I think it's time to take our library QA tools to the next level. > (It also could have repercussions for buildds, if there are symbols that > only exist on a particular architecture.) Yep. And glibc happens to be the chief candidate for that, unfortunately. Also an issue are any C++ libs being built using different compilers on different architectures. So there does seem to be a need for per-architecture override lists. I'm not sure how user-friendly the support for that would need to be initially, though. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature