Re: SONAME best practice
[Andy Hawkins]
> I think I'd prefer libmb5.so...., as it maintains consistency with the
> libmb3 packages.
>
> It's also clearer to the person installing it exactly what they're getting.
> Otherwise, the libmb3 packages would have been called libmusicbrainz-6,
> which doesn't obviously tell them which version of the API they're
> installing.
By and large, end-users do not care about the SONAME itself, which is
buried somewhere in /usr/lib. (Actually these days, /usr/lib/{triplet}
is preferred, where {triplet} is something like x86_64-linux-gnu, but
as an upstream developer you don't really have to care about that, the
Debian maintainers will handle it.) The "user-visible" point is really
the -dev package, something like libmb-dev. That's where you want
people to know which API they will be using. (The SONAME, or library
ABI, is a side effect they probably don't need to care about directly.)
Typically you just do a single -dev package that tracks the "current"
ABI. Downstream developers (and people who build downstream software)
just need to install, e.g., libmb-dev, and link with '-lmb', which the
linker will resolve because your -dev package ships /usr/lib/libmb.so
as a symlink to libmb.so.5 or libmb-6.so.1.0.4 or whatever.
But it may be that you want users to be able to choose which API to
build against. In that case you want to maintain two or more source
packages in parallel, each shipping a -dev package with a distinct
name, e.g., libmb5-dev and libmb6-dev. Downstream developers can
install either -dev package, though not necessarily both at once.
(Things can get confusing if you support installing both -dev packages
at once, e.g., where should users find their header files? You can
support two-at-once with mandatory distinct -I and -l flags, but the
simpler way is for your -dev packages to conflict with each other.)
Either way, you have a choice, whether each -dev package should ship a
symlink /usr/lib/libmb.so, or a symlink /usr/lib/libmbN.so, or both.
The symlink(s) would point to whatever your real SONAME is for version
N. And the symlink(s) are the real downstream-facing interface: they
determine whether downstream software should be built with "-lmb" or
"-lmbN".
I guess I didn't answer the _original_ question. The SONAME scheme.
In the end it doesn't matter too much, downstream users shouldn't
really notice it. I'd opt for the simpler libmb.so.N and package name
'libmbN', but there's nothing really wrong with the other major style,
libmb-N.so. Doing both in the SONAME (libmb-N.so.M) doesn't seem very
useful, IMO. If you really feel the need to distinguish the ABI with
two integers instead of one, I suggest the libdb style, libmb-N.M.so.
Peter
Reply to: