Re: Debian upload of 0.0.27?

[Simon Josefsson]

Russ Allbery <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> I'm preparing the Debian package for 0.0.27.
>
>> Would it be OK to drop shishid now?  The current package has entered
>> testing, and been there for a while, and I doubt anyone will install the
>> old broken packages that only ever were in unstable.
>
> Yup, no problem.

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

Package: shishi-kdc
Conflicts: shishid
Replaces: shishid

?

>> I also noticed that 'shishi' and 'shisa' doesn't depend on a particular
>> version of libshishi0 or libshisa0, see:
>
>> http://packages.debian.org/testing/net/shishi
>> http://packages.debian.org/testing/net/shisa
>
>> This is probably a bad idea, I'll try to make the dependency contain
>> the package version.
>
> Hm, so shishi and shisa are not typical clients of those libraries and
> would be affected by changes to those libraries that other programs
> linking to those libraries wouldn't care about?

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.

I understand the correct solution is to start using shared library
versioning, but this is some work.  Can we solve the problem by using
versioning on the Debian packages instead?  Is there any strong policy
wording on this?

I think this issue is the only open issue until we can upload new
packages.

(I just checked, and I believe no Debian version has had any ABI
version incompatibility, but that was probably just luck, or because
the changes in the last few releases were minor and mostly to fix
debian packaging.  That means we can still solve the problem cleanly,
by having 0.0.27 use libshishi1...)

Hm.  I just had the idea that I could use the libshishi-0.0.27.so
approach, which libtool support.  If you dislike the above approach,
would this be better?  I'm not sure it solves the problem anyway,
binary packages still seem to have to depend on a particular library
version.

Thoughts on what the best solution is here are appreciated.

Thanks,
Simon