On Tue, 2008-01-15 at 12:50 +0000, Mark Brown wrote: > On Tue, Jan 15, 2008 at 10:44:32AM +0000, Neil Williams wrote: > > On Tue, 2008-01-15 at 09:35 +0100, Stefano Zacchiroli wrote: > > > On Mon, Jan 14, 2008 at 06:56:18PM +0000, Neil Williams wrote: > > Instead, the maintainer needs to work with upstream to convince them of > > the importance of a stable API/ABI over a series of releases, > > coordinated SONAME transitions and other issues around the versioning of > > the library. Otherwise, the maintainer will have quite enough to do with > > constant package name changes to keep up with the consequences of > > upstream not retaining a stable ABI. If the library changes API at every > > release, a symbols file won't help anyone because applications using the > > library will have to make a transition anyway. A symbols file is only > > Right, as you say the problems here are nothing to do with symbols > files or symbol versioning. A poorly maintained library is going to > create trouble no matter what and a well maintained library should be > fine even if it does not use versioned symbols. > > For example, the zlib library has never had a soname bump because > upstream are careful to only add new interfaces. I'm not sure zlib is a good example - when I built the current sources (which contained the symbols file), I got a lot of lintian warnings about the symbols. Reminder: the symbols file provided by mole *needs editing*. In particular, the Debian version needs to be stripped off (not sure why this isn't done already) for reasons explained on the Wiki page. I've got a few more things to do elsewhere in QOF before the new version with versioned symbols and symbols file support can be released. I've also got working symbols for libgpewidget (which has used versioned symbols for a long time alreayd) that will be implemented in the next upload, as well as a few others. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part