[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [odin-devel] Broken (lib)vista version number



Il giorno Tue, 29 Jan 2008 19:45:52 +0100
Thies Jochimsen <thies@jochimsen.de> ha scritto:

> Hi David,

Hi Thies,

> > I was going to package both odin and vista.
> 
> That is great news!

I'm glad you replied -- from the list archives, seems like there is not
activity since March 2007 :). I feared my mail went in /dev/null ;)

> > I've searched for that version number (2.0.2) in the whole source tree
> > with:
> >
> > $ grep -nR "2\.0\.2" *
> 
> I assume that you have used the vista source code package from the odin 
> download page. The culprit is in the Makefile.am of the vista subdirectory:
> 
> http://od1n.svn.sourceforge.net/viewvc/od1n/trunk/vista/vista/Makefile.am?view=markup
> 
> it is the option '-version-info 2:2:0' to libvista_la_LDFLAGS. Please note 
> that the two last digits get reversed for the file name of the installed 
> library.

I supposed it was that, but wanted to be sure ;)

> According to the specs of libtool
> 
> http://sourceware.org/autobook/autobook/autobook_91.html#SEC91 
> 
> the last digit (age) must be less than or equal to the first (current). Thus, 
> as a quick hack, I have always set it to zero. But this can certainly be 
> changed on my side in the repository, i.e. to  '-version-info 2:1:2' . I am 
> not an expert on library versioning. Any suggestions on how to fix this issue 
> are welcome...

Well, I suppose that the relevant bit is:

---8<---
For later releases of a library, the `-version-info' argument needs to be set
correctly depending on any interface changes you have made. This is quite
straightforward when you understand what the three numbers mean:

   1. If you have changed any of the sources for this library, the revision
number must be incremented. This is a new revision of the current interface.

   2. If the interface has changed, then current must be incremented, and
revision reset to `0'. This is the first revision of a new interface.

   3. If the new interface is a superset of the previous interface (that is, if
the previous interface has not been broken by the changes in this new release),
then age must be incremented. This release is backwards compatible with the
previous release.

   4. If the new interface has removed elements with respect to the previous
interface, then you have broken backward compatibility and age must be reset to
`0'. This release has a new, but backwards incompatible interface. 

    For example, if the next release of the library included some new commands
for an existing socket protocol, you would use -version-info 1:0:1. This is the
first revision of a new interface. This release is backwards compatible with
the previous release.

    Later, you implement a faster way of handling part of the algorithm at the
core of the library, and release it with -version-info 1:1:1. This is a new
revision of the current interface.

    Unfortunately the speed of your new implementation can only be fully
exploited by changing the API to access the structures at a lower level, which
breaks compatibility with the previous interface, so you release it as
-version-info 2:0:0. This release has a new, but backwards incompatible
interface. 
--->8---

This means that, for example, 2.1.2 (i.e. 2:2:1) is backwards-compatible with
2.0.2 (i.e. 2:2:0). In our case, then, it should be 2:1:2 (to have 2.2.1), but
according to the definition of "age", this is an impossible version number
(i.e.: the revision is 1, it's impossible to be backwards 2 revision before).
Maybe someone on debian-med can help us? Otherwise we could also ask on
debian-devel (where the gurus are :p) :)

> > but had no luck. In fact, it seems like everything is correctly setting
> > 2.2.1. Could you please point me where this strange number comes from? If
> > you believe it's not worth making a new release, I'll make a
> > "Debian-specific" patch to fix it.
> 
> It is certainly worth, please let me know what to change for a clean vista 
> debian package.

Well, first of all, rip off any debian/ directory from your sources :)
That directory is not meant to be included upstream; it's our job ;).

Please, let me know if you can make any release asap, or if I should package
the whole thing by patching it!

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

Attachment: signature.asc
Description: PGP signature


Reply to: