Re: Debian upload of 0.0.27?

[Simon Josefsson]

Russ Allbery <address@hidden> writes:

> 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.

Done.

>> 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.

I see.  I read section on libraries in the Debian Policy manual, but
I'm probably missing something, because it answers few of the
questions I had.  I'm only familiar with cdbs, and not the underlying
dpkg package architecture, which makes it more difficult to understand
the document.

> 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.

Ah, I see.  I've seen that in several other packages.  I actually
experimented with that too, but I tried to avoid the hard coded
version and put some variant of ${Source-Version} or ${source:Version}
but it didn't work.  Is there no way to do this, or did I do something
wrong?

I fear that I'll forget to bump that version number with new packages.

I'll try this now.

>> 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.

If I bump the major symbol version every time I add a new symbol,
which is what I believe the libtool manual recommends, I think it
would work.  But it will generate a lot of libshishi0, libshishi1,
libshishi2 very fast.  I do that for gnutls, that has a much more
stable API, but still there is libgnutls11, libgnutls12 and
libgnutls13 in Debian.

> Tighter dependencies are what is needed here, which is what the
> Debian shlibs system provides.

Yes, that seems much better.

>> 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.

Ah, that was the piece of information I was looking for in the policy
manual.  It described SONAME and similar, but never discussed when it
must be incremented and when it must not be incremented.  I may have
missed something, though.

> 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.

Ok.

/Simon