On Mon, 16 Apr 2007 09:27:48 +0200 Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 15, 2007 at 10:39:50PM +0100, Neil Williams wrote: > > > If there are no changes in ABI between libarchive1 and > > > libarchive2, the best here is to revert the package rename, if > > > necessary keeping a libarchive.so.1 -> libarchive.so.2 compat > > > symlink in the package for compatibility both with upstream and > > > with previous Debian versions. > > > Steve: Can I check I've understood that correctly? I would create a > > patch that reverts the SONAME change in the autotools by breaking > > the link between the upstream version string and the library > > version info and setting version info directly. > > I would instead leave the upstream code alone, and provide > libarchive.so.1 as a backwards-compatible symlink to libarchive.so.2, > permitting the package name to be reverted to libarchive1. OK - I'm reworking the patch that way around. > > No Replace: is needed at this stage, libarchive2 is essentially > > empty and described in debian/control as a transitional package. > > In my suggested solution, libarchive1 should Conflicts/Replaces: > libarchive2 (and Provide: it too, if you're keen). Will do. > > If, at a later date, libarchive DOES break the current API/ABI, a > > new build of libarchive would set SONAME=2, build the new > > libarchive.so.2, drop the libarchive1 package from debian/control > > and the symlink would be removed when the old libarchive2 > > transitional package is superceded by the new version. The > > dependency on libarchive1 would be removed at this time. This (if > > I've got it right) would result in the new ABI libarchive2 being > > installable alongside the current ABI libarchive1, except that the > > issue of the manpage would still need to be resolved with a > > Replaces: libarchive1. > > If at a later date libarchive breaks the current API/ABI, upstream > should bloody well be required to fix it to not continue to use > SONAME=2 since there is already an incompatible lib in existence with > that soname. It should go to libarchive3, and then yes, it will be > coinstallable with libarchive1 regardless of any use of Provides: > above (and modulo any Replaces: needed for manpages). :-) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpfKJEdMgFso.pgp
Description: PGP signature