Re: Please consider a binNMU on reprepro due to libarchive transition.
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. Doing it the other way has the downside
that any binaries built on Debian will be incompatible with other systems.
Providing the symlink in this direction also requires that the shlibs be
bumped, since new packages built against libarchive1 will need
libarchive.so.2 instead of libarchive.so.1, so the shlibs must be versioned
to specify a dep on the new version of the package.
> This would generate a new
> libarchive1 binary package at version 2.0.25-2.1 from the libarchive
> source package and update libarchive-dev 2.0.25-2.1 to depend on
> libarchive1 == 2.0.25-2.1. In debian/control, I would also create a
> dummy libarchive2 package that only contains a symlink: libarchive.so.2
> -> libarchive.so.1 in /usr/lib. This libarchive2 transitional package
> would have to depend on libarchive1 >= 2.0.25-2.1 to prevent a dangling
> symlink.
I don't see any value in providing two binary packages here, that's pretty
bloaty for a change that's being reverted after only a month in unstable and
affecting only a handful of packages.
> I then rebuild deb-gview source against libarchive-dev (unversioned) to
> regain a binary deb-gview dependent on libarchive1 (this time at
> 2.0.25-2.1) and upload it to unstable. reprepro would be completely
> unaffected.
As far as rebuilds go, this should still be correct.
> 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).
> 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).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: