* From: Steve Langasek * Date: Tue, 5 Jun 2007 02:56:14 -0700 > > On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote: >> On Mon, 04 Jun 2007, Steve Langasek wrote: [] >> > Considering the number of bugs I see because of maintainers who don't >> > notice >> > they need to change package names due to upstream soname changes, or who >> > routinely fail to bump their shlibs when new symbols are added, I think >> > there is definitely room here for a recommended solution for maintainers >> > that aren't watching the subtleties, even without trying to bump >> > dependencies based on API extensions. > >> Would you care to elaborate? (What would you recommend? How do you expect >> it to improve the situation with those maintainers?) > > Maintaining library symbol files with a tool that updates the symbol lists > with behavior analogous to dh_makeshlibs -V would be a significant > improvement over either dh_makeshlibs -V (force a shlibs bump for every > rev), or dh_makeshlibs alone (get too weak shlibs for any API additions). > > Throwing a sensible error at build-time if the soname has changed without a > package name change is also something that needs to be done, as well as > throwing an error at build-time if symbols listed in the symbols file have > gone missing; I don't see these features mentioned in your proposal, but I > think they're part and parcel of a good implementation of what you're > describing.
If one will take look in the message with subject "checklibs...", one will see similar items in the wish list on top of the script. But i don't know much (yet) about build infrastructure to store information script already (and can easily) generate. For colleagues with python implemented ELF parsing, i will suggest to help either elfutils, or binutils with their TODO lists. ____ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
