On Fri, Dec 07, 2018 at 08:27:24AM -0800, John Horigan wrote:
> I maintain a static library package, libagg-dev. There is an outstanding
> request for a shared library of libagg.
Is building the shared lib supported by the upstream?
Yes, but the the package maintainer before me made it a static-only package. libagg 2.4 is API incompatible with libagg 2.3 and the upstream developers did not follow semantic versioning by setting the version to 3.0. The package maintainer did not understand that ABI versions (current:revision:age) do not need to match the upstream version scheme. The library version for libagg2.4 is 2:4:0 for no good reason at all.
Upstream is going to bump the version to 2.6 (skipping 2.5 because of an abandoned agg2.5 fork). I plan to change the ABI version to 2:0:1. Technically the ABI version should be 3:x:y because of the agg2.3 to agg2.4 API changes. But that happened 9 years ago, so I don't see the point.
> libagg2-dev has the .so file with the name libagg.so and libagg2 has the
> .so file with the name libagg.so.2.0.4 and the symlink libagg.so.2.
You shouldn't put the soname version into the -dev package name.
And libagg.so is a symlink to libagg.so.2, not its copy.
> I also put in lintian overrides because libagg2-dev installs a .so file
> with the SONAME libagg2 but the package is called libagg2-dev:
You should not override this, of course.
With your input and help from Wookey I have removed all of my lintian overrides. I'm still trying to resolve whether I need two -dev packages or one.
--
WBR, wRAR