On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote: > On Mon, 04 Jun 2007, Steve Langasek wrote: > > On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote: > > > I agree that the benefits are worth the deal, but we should make clear > > > that the price to pay for these benefits is a continuous effort from the > > > maintainer. Therefore it should not be used by maintainers not aware of > > > its subtleties.
> > 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. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
