Need to update micro version in shlibs file when symbols are added

[Michi Henning]

Currently, we are writing only major.minor into the shlibs file. But, if we add a new symbol to the public API and only increment the micro version, we really need to write the micro version as well.

Unfortunately, that's a manual process, so we need to remember. With the next version of abigail, it might be possible to spit out some big-time warning or some such when new symbols are added to the public API. At least that would help to remind us.

[James Henstridge (jamesh)]

The shlibs file should read something like:

    libunity-scopes 1.0 libunity-scopes1.0 (>= 1.0.x)

Where 1.0.x is the last release where new ABI was introduced (currently it omits the version assertion on the end).

For mediascanner2, I am not generating the shlibs file from anything, but instead manually update it. It's not perfect, but I'm not sure of a better alternative yet.

[Michi Henning (michihenning)]

The version assertion should be there. In the shlibs.in file, we have

libunity-scopes @UNITY_SCOPES_SOVERSION@ libunity-scopes@UNITY_SCOPES_SOVERSION@ (>= @UNITY_SCOPES_MAJOR_MINOR@)

But the micro version is missing here.

[James Henstridge (jamesh)]

I'm not seeing it in the final packages though:

    $ apt-cache policy libunity-scopes1.0
    libunity-scopes1.0:
      Installed: 1.0.3+16.04.20160209-0ubuntu1
      Candidate: 1.0.3+16.04.20160209-0ubuntu1
      Version table:
     *** 1.0.3+16.04.20160209-0ubuntu1 500
            500 http://au.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
            100 /var/lib/dpkg/status

    $ cat /var/lib/dpkg/info/libunity-scopes1.0\:amd64.shlibs
    libunity-scopes 1.0 libunity-scopes1.0

In contrast, for mediascanner:

    $ cat /var/lib/dpkg/info/libmediascanner-2.0-4\:amd64.shlibs
    libmediascanner-2.0 4 libmediascanner-2.0-4 (>= 0.110)

I'm guessing that the shlibs file in the build tree is being ignored, so the package ends up with the default one instead.

[James Henstridge (jamesh)]

A bit more info: I ran the gen-debian-files.sh script, and it produced the following files:

    libunity-scopes-1.0.2.shlibs
    libunity-scopes-qt0.2.0.shlibs

Neither of these match the binary package names (libunity-scopes1.0 and libunity-scopes-qt0.2 respectively), which is probably why they are being ignored.

This still leaves open the issue of how to manage the minimum version requirement. At the moment these files produce:

    libunity-scopes 1.0 libunity-scopes1.0 (>= 1.0)
    libunity-scopes-qt 0.2 libunity-scopes-qt0.2 (>= 0.2)

The first is wrong because there have been ABI additions since version 1.0. The second looks weird because it doesn't look like it refers to any released version -- that binary package has the same version numbering as the rest of them, so I'd expect a 1.0.x version as minimum.

[Michi Henning (michihenning)]

Ouch! :-(

Thank you for the detective work!

I'll fix the script to generate the the correct file names. To get the correct micro version in there, we'll have to use a manual process, I'm afraid, at least until it somehow becomes possible to have abigail help with detecting symbol additions to the public API.

For the qt lib, it really was never officially release, and everything is still in an experimental namespace. I don't believe the version for this has ever been anything other than 0.x.

[James Henstridge (jamesh)]

The version numbers in at the end of the shlibs lines refer to package version numbers. Every binary package produced from the source package will share the same version number.

Given that unity-scopes-api 0.2 seems to date from 2014, which is long before the Qt library was written, it certainly looks bogus.

[Michi Henning (michihenning)]

Looking at this, I think the easiest way would be to generate the final digit in the dependency clause from a separate file, say, LAST_ABI_ADDITION_MICRO.

So, if we release 1.0.6, but there were no ABI additions from 1.0.5 to 1.0.6, we would have VERSION containing "1.0.6", and LAST_ABI_ADDITION_MICRO containing "5". This then would generate

$ cat libunity-scopes-1.0.shlibs
libunity-scopes 1.0 libunity-scopes1.0 (>= 1.0.5)

even though the package version is 1.0.6.

We will have to remember to update the LAST_ABI_ADDITION_MICRO file if we add anything new to the public API.

Opinions?

Longer term, we may still be able to come up with something that leverages abigail, but I'd prefer to have a fix for this now rather than later.