On Mon, 29 Sep 2008 18:40:47 +0200
Leopold Palomo Avellaneda <leo@alaxarxa.net> 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/
Attachment:
pgpGNJ9fdtufg.pgp
Description: PGP signature