Russ Allbery <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> 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 _______________________________________________ Help-shishi mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-shishi
