A Dilluns 29 Setembre 2008, Neil Williams va escriure: > 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.
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
signature.asc
Description: This is a digitally signed message part.
