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: > > Quick summary: IMHO, symbols files are largely irrelevant if not > > supported upstream via versioned symbols. > > Can you please argument this? (You omitted the rest of that paragraph which contained my reasoning for that statement) > Versioned symbols are largely > useless if the upstream maintenance is generally poor or has a > particularly poor understanding of libtool versioning. Versioned > symbols > involve continuous maintenance upstream every time a symbol is > modified > (e.g. new functions added) but have no effect on changes within > functions that do not modify the function prototype itself. Symbols > files involve regular maintenance by the Debian maintainer. Symbols files need data from --version-script in order to calculate much more than a static list of symbols. i.e. generating symbols for a library that does not use versioned symbols will end up with a list that has no history. Each time you generate it, the list of symbols will be "new" when they are not. If --version-script is not used, the list of symbols uses the same version for all symbols - but each time you create a new release you generate a new symbols file (because no versioned symbols exist) and all the versions increment to the current release as if they were all new. e.g. libqof.so.1 libqof1 #MINVER# LIBQOF_0.7.2@LIBQOF_0.7.2 0.7.2 QofBackendErrorasString@LIBQOF_0.7.2 0.7.2 QofDateErrorasString@LIBQOF_0.7.2 0.7.2 QofLogLevelasString@LIBQOF_0.7.2 0.7.2 ... at v0.7.3 becomes libqof.so.1 libqof1 #MINVER# LIBQOF_0.7.3@LIBQOF_0.7.3 0.7.3 QofBackendErrorasString@LIBQOF_0.7.3 0.7.3 QofDateErrorasString@LIBQOF_0.7.3 0.7.3 QofLogLevelasString@LIBQOF_0.7.3 0.7.3 ... That's wrong because those symbols existed in 0.7.2 and have not changed in 0.7.3 (or actually some might have changed but without versioned symbols you cannot tell). With --version-script implemented upstream, the symbols file is unchanged if the symbols really have not changed - or if a symbol has changed, it can be shown in the symbols file. In the actual example above, none of those symbols have changed so the symbols file for 0.7.3 is identical to that in 0.7.2. If I add a new function in 0.7.4, the symbols file could be: libqof.so.1 libqof1 #MINVER# LIBQOF_0.7.4@LIBQOF_0.7.4 0.7.4 LIBQOF_0.7.2@LIBQOF_0.7.2 0.7.2 QofBackendErrorasString@LIBQOF_0.7.2 0.7.2 QofBackendErrorFromString@LIBQOF_0.7.4 0.7.4 QofDateErrorasString@LIBQOF_0.7.2 0.7.2 QofLogLevelasString@LIBQOF_0.7.2 0.7.2 ... (Note that this requires that upstream, the --version-script implements LIBQOF_0.7.4 for the new symbol. This example is also over simplified and might not represent the real effect of such a change.) So, whilst you can generate a symbols file from any condition, a symbols file only provides useful data, IMHO, if --version-script is implemented upstream so that the symbols file has something to back it up. --version-script is not something that can be easily implemented by the Debian maintainer without upstream cooperation because updating the version script involves detailed knowledge of the upstream changes as well as a stable ABI/API across a series of releases. It's easy for me with the QOF library because I am upstream. It might be possible with smaller libraries that change infrequently but then those are not the libraries that typically need such support. The most important consideration is that if upstream do not know or care about versioned symbols, the library API is likely to be poorly maintained and the symbols file would be useless anyway. i.e. if upstream do not know or care about versioned symbols, upstream is likely to have a poor understanding of libtool versioning and poor API maintenance in general and the work involved in correcting things in the Debian package is probably not worthwhile. 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 useful if retained across a series of releases and the symbols data should not include the Debian version number (lintian error) so that means a series of upstream releases. If the ABI/API changes at every upstream release, the symbols file doesn't help. If upstream really don't care about a stable ABI/API, upstream are not going to care about --version-script or versioned symbols and the constant ABI/API changes render symbols files meaningless, IMHO. Quite what that means for the future of such a package in Debian, I'm not quite sure but I know it means a lot more work for the Debian maintainer. -- 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