Hi, 

While packaging the 0.3.2a1 version of generatorrunner for Debian, I noticed
some unclear things on the libgenrunner front :

The source produces a binary /usr/lib/libgenrunner.so.0 and two
/usr/lib/libgenrunner.so.0.3.2 and /usr/lib/libgenrunner.so symlinks to it.

This scheme indicates that the soname of the library should be 0, where it is
defined as 0.3.2.

This is not "per se" a problem, but bad things happen when the library is
updated : as per Debian Policy, the binary package name has to match the
SONAME, so I had prepared libgenrunner0.3.1 and I was about to release
libgenrunner0.3.2. BUT (apart of the fact that I have to go trough an
additional level of review because a new binary package is added), the file
/usr/lib/libgenrunner.so.0 is present in two different binary packages, and by
such, cannot be installed side by side (where they should be able to, as they
are different packages).

Now I see two reasoning paths :

1) the ABI is breaking at each *.*.x release, so we shouldn't get a *.so.0
symlink, but only *.so.0.3.1 (e.g) binary and a *.so symlink (for the -dev
package). With that reasoning, the package would be named libgenrunner0.3.2 and
would change at each MICRO_VERSION bump (and would need to go through NEW each
time).

2) the ABI is only breaking at *.x.* releases, so we should get a *.so.0.3.1
binary and a *.so.0.3 symlink and a *.so symlink (for the -dev package)
With that reasoning, I would name the package libgenrunner0.3 and it would only
change at each MINOR_VERSION (ditto)

3) (take the same reasoning for x.*.* releases).

What is certain to me is that the current scheme is clearly suboptimal.

Best regards, 

OdyX