Re: Debian upload of 0.0.27?

[Russ Allbery]

Simon Josefsson <address@hidden> writes:

> Ok.  Is it sufficient for shishi-kdc to have:

> Package: shishi-kdc
> Conflicts: shishid
> Replaces: shishid

> ?

Yup.  Or we could even drop that, given that shishid was only ever in
unstable as I recall and is now history.

> They are typical clients, but so far I haven't paid attention to bump
> the library ABI whenever I add new APIs.  There has simply been too many
> ABI additions so far.  Shishi/shisa may use APIs only found in the
> latest libshishi.

> For example, in the upcoming 'shishi' package, the tool 'keytab2shishi'
> uses new APIs in libshishi 0.0.27.  So if someone upgrades the 'shishi'
> package to 0.0.27 without upgrading 'libshishi0' to 0.0.27,
> keytab2shishi won't work.

Oh, that's what shlibs is for.

Using cdbs, you set DEB_DH_MAKESHLIBS_ARGS_<package> to the appropriate
flags.  See the man page for dh_makeshlibs, but basically you want to
include a -V flag for each library specifying the last Debian package in
which new symbols were added.  So, for instance, you probably want:

    DEB_DH_MAKESHLIBS_ARGS_libshishi0 = -V'libshishi0 (>= 0.0.27)'
    DEB_DH_MAKESHLIBS_ARGS_libshisa0 = -V'libshisa0 (>= 0.0.27)'

Then the right thing will happen with all other packages automatically.

> I understand the correct solution is to start using shared library
> versioning, but this is some work.

Symbol versioning doesn't actually help with this, since the old library
doesn't know that you're going to introduce new symbols and couldn't
implement them anyway.  Tighter dependencies are what is needed here,
which is what the Debian shlibs system provides.

> Can we solve the problem by using versioning on the Debian packages
> instead?  Is there any strong policy wording on this?

The name of the Debian package should patch the SONAME, which you only
need to change if you're removing interfaces or making changes to
interfaces that aren't backward-compatible.  That deals with the problem
of old binaries not working with new libraries, which is the opposite
problem of what shlibs deals with.  shlibs deals with new binaries not
working with old libraries.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>