On Mon, 29 Sep 2008 18:40:47 +0200 Leopold Palomo Avellaneda <[EMAIL PROTECTED]> wrote:
> > > Upstream uses autotools, but not in a very correct way, I guess. The > > > library is 3.5.6 version, but the configure + make creates > > > libXXX.so.0.0.0. I have looked on the configure.ac, Makefile.am, etc, and > > > I have not seen any place to pass a parameter to libtoolize. So, how can > > > I "correct" this bug in upstream? > > > > IT IS NOT A BUG! > > > > The version of a library has nothing to do with the SONAME. Please read > > the libtool manual. > > Yes, you are right. But I prefer the Debian library packaging guide, it's > more > clear in this aspect. However I guess than the author uses the version number > as the SONAME number and don't know how to change it. Eh? If the library version is 3.5.6 and the SONAME is 0.0.0, then that is good and correct. http://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning > Because I think that > the different versions of the library have broken the binary compatibility. > But, if I should leave the version numbers as the authors want, no problem. Broken binary compatibility between versions that do not currently exist in Debian are of no consequence to Debian. What matters is now - educating upstream to tweak the libtool versioning *separately* from the version string when the ABI next changes. Take a look at my own library (upstream and Debian) - QOF. configure.ac: AC_INIT([qof],[0.8.0], [http://lists.sourceforge.net/lists/listinfo/qof-devel]) AC_PREREQ(2.61) AC_GNU_SOURCE LIBQOF_LIBRARY_VERSION=2:0:0 LIBQOFSQL_LIBRARY_VERSION=1:1:0 Makefile.am: libqof_la_LDFLAGS= -version-info $(LIBQOF_LIBRARY_VERSION) \ $(LINKER_SCRIPT) -L${top_builddir}/lib/libsql That is how the SONAME should be set. If your upstream are less knowledgeable about libtool and ABI, SONAME changes, educate them using the libtool manual (they won't care much about the Debian Library Packaging Guide) and ensure that they update the LDFLAGS in the relevant Makefile.am to denote when the next ABI/SONAME change happens. Also get them to think about gradual SONAME bumps by migrating old functions to a deprecated.c or similar file with appropriate conditionals to support a --no-deprecated option to ./configure such that reverse dependencies can build against the library as it would be AFTER the SONAME bump and detect problems early. Packaging libraries is a complex task - do NOT do it unless you are confident that you can work with upstream to get it right. If you don't understand the GNU libtool manual, then forget this package right now. Please don't add another broken library to Debian. Get them to implement versioned symbols properly as well. Generally, maintainers should package several "ordinary" binary packages BEFORE even considering a library. > > > And my last question is examples. Upstream has a directory with some > > > examples, but they are not installed (noinst_PROGRAMS), so, should I to > > > patch sources to install them? Or simply, do I copy the files? > > > > noinst_PROGRAMS should not be packaged, generally. Some can be upstream > > test cases. > > In this case are examples. If you can locate them during the build and they could be useful to others (without being compiled), then put them in /usr/share/doc/$package/examples/ -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpLGeQ3oQzjH.pgp
Description: PGP signature
