A Dilluns 29 Setembre 2008, Neil Williams va escriure:
> 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.
Yes ... but I guess that upstream have broken the ABI in the several versions
of the library.
> 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.
indeed.
> What matters is now - educating upstream to tweak the libtool
> versioning *separately* from the version string when the ABI next
> changes.
Uff. Who am I to try to educate to upstream? :-) I can try to send an email
about it, but ...
> Take a look at my own library (upstream and Debian) - QOF.
you use cdbs ... I don't like it, but it's just my opinion....
> 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.
That's what I wanted to know!!!! But I will not patch upstream.
> 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)
Ok, I put the example because Debian Library Packaging Guide explain this kind
of things in a very good way, so, although you don't want to create a debian
package, it gives you a lot of useful information.
> and ensure that they update
> the LDFLAGS in the relevant Makefile.am to denote when the next
> ABI/SONAME change happens.
Ok, I will prepare a mail with all this information to "educate" upstream.
[...]
>
> Packaging libraries is a complex task - do NOT do it unless you are
> confident that you can work with upstream to get it right.
I know that is a complex task, but it's a nice task because you learn a lot of
packaging.
> If you don't understand the GNU libtool manual, then forget this
> package right now. Please don't add another broken library to Debian.
It's not a question of understanding, I have just said that I prefer how is
explained in the Debian Library Packaging Guide. And, I don't want to add any
broken library, of course.
> Get them to implement versioned symbols properly as well.
Ok.
> Generally, maintainers should package several "ordinary" binary
> packages BEFORE even considering a library.
Yes, this is the first thing that I thought. But, my main problem is that the
software that I would like to package (because I like or I use or I think
intersting, etc), in general _ALL_ are libraries, so what's supposed that
should I to do?
Package a software that I don't like, or I don't use?
I'm not be able to maintain a package that I don't use/like. I prefer to make
the afford to package something to me important.
[...]
>
> 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/
They are build with autotools, so they are not very useful without a plain
makefile. But I can build one.
On the other hand, you have point me about something important that I have
missed, that it's contact with upstream. So, I will do it.
Thanks for all the comments,
Leo
PS the package is solid
http://www.dtecta.com/files/solid-3.5.6.tgz
SOLID is a software library for collision detection of geometric objects in 3D
space.
--
--
Linux User 152692
PGP: 0xF944807E
Catalonia
Attachment:
signature.asc
Description: This is a digitally signed message part.