The first version of libswe in debian
was 1.77.00. so the value of --version-info was 0:0:0

libswe_la_LDFLAGS =3D \
        -version-info 0:0:0 \
        -lm         \
        -export-symbols-regex ^swe_

Note only symbols beginning swe_ are exposed.

version 1.78.00 which was never released, added
a new symbol beginning swe_ but it did not change
the meaning of any of the old ones so the
--version-info for that version should be 1:0:1

I built and checked that version privately, so I
consider it a "virtual release".

Version 1.79.00 does not add any new swe_ symbols at all over 1.78.
But new "#define" preprocessor constansts are added,
and the old functions produce new results for these constants.


In addition some of the 1.78.00 behavior was a bug. It produced
the wrong answer. This has been fixed so that the 1.79.00
gives the correct documented answer.

Under these conditions what is the proper value for
1.79.00 --version-info?

The reason for my confusion is this section of Libtool: 
7.3 Updating library version information
https://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
It says:

        The following explanation may help to understand the above
        rules a bit better: consider that there are three possible
        kinds of reactions from users of your library to changes in a
        shared library:

     1. Programs using the previous version may use the new version as
        drop-in replacement, and programs using the new version can
        also work with the previous one. In other words, no
        recompiling nor relinking is needed. In this case, bump
        revision only, don't touch current nor age.

     2. Programs using the previous version may use the new version as
        drop-in replacement, but programs using the new version may
        use APIs not present in the previous one. In other words, a
        program linking against the new version may fail with
        "unresolved symbols" if linking against the old version at
        runtime: set revision to 0, bump current and age.

     3. Programs may need to be changed, recompiled, relinked in order
        to use the new version. Bump current, set revision and age to
        0.  In the above description, programs using the library in
        question may also be replaced by other libraries using it.

I believe that 1) is not true. Because 
        "and programs using the new version can also work with the
        previous one"

is not true. They will try to use the new "#define" in the .h files
and they will not work.

The first part of 2) is true:
        "Programs using the previous version may use the new version
        as drop-in replacement, but programs using the new version may
        use APIs not present in the previous one."
but the second part of 2) is not true:
        "In other words, a program linking against the new version may
        fail with "unresolved symbols" if linking against the old
        version at runtime"
This is not true because the linker never sees the new interface. It
is hidden by new behavior on calls with new "#define" in constants.

3) is not true.

So the answer depends on weather I should count 2) as true!

What do the Debian experts think?

I always update the debian/libsweX.symbols file for a new
release. In this case it shows no new symbols.

Thank You.




-- 
Paul Elliott                               1(512)837-1096
pelli...@blackpatchpanel.com               PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden

Attachment: signature.asc
Description: Digital signature

Reply via email to