On Sun, 15 Apr 2007 14:48:30 +0200 Steve Langasek <vorlon@debian.org> wrote: > Hi Neil, > > On Sat, Apr 14, 2007 at 08:36:45PM +0100, Neil Williams wrote: > > Regarding #418637. > > > I've prepared a new release of deb-gview which Build-Depends on > > libarchive-dev. libarchive1 has been replaced by libarchive2 in > > unstable but I cannot find any ABI/API change as yet - I use > > deb-gview and reprepro regularly (I suspect others would use the > > two together as well) and when I recompiled deb-gview and reprepro > > against libarchive2, both compiled and functioned perfectly. > > > I'm ready to make an upload of deb-gview and I'm wondering if a > > binNMU of reprepro is worthwhile to allow deb-gview, libarchive2 > > and reprepro to be installable together. > > > It does seem to be working around the problem in libarchive, rather > > than fixing it, so I'm really asking whether a binNMU of reprepro > > is the best solution to #418637. After a more thorough check of the two versions, all I can find is bug fixes and one new function added. I'm not the maintainer for libarchive (hence CC'ing the bug report which I should have done before) but I'll happily do an NMU to the delayed queue. The patch would involve undoing some of the autotools automation where it creates the version data from the tarball version string - it appears to me that this is what led to the library being compiled with a SONAME of 2 when the version of the tarball moved to 2.0. I fail to see why any library should tie the SONAME so closely to the version string - the GNU libtool docs strongly advise against such actions. [0] (e.g. my own library package, libqof1 is at v0.7.2 and is likely to migrate to libqof2 at v0.8.0, other libraries have SONAME==0 || 1 when the version string is >2.) > 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. 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 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. No Replace: is needed at this stage, libarchive2 is essentially empty and described in debian/control as a transitional package. 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. Correct? > If there is some reason that this solution would be inadequate I will > be happy to schedule binNMUs, but from here it looks like that would > be a wrong fix. > > Thanks, John: can you confirm that the package name was changed ONLY as a result of the SONAME being calculated from the upstream tarball version string? (and thereby spent an avoidable period in the NEW queue). Are you happy for me to revert this and retain libarchive1 at version 2.0.25-2.1 by setting the library version separately from the version string, as recommended above? Do you have the time to do this yourself or do you have any objection to an NMU of libarchive? (Do you want a co-maintainer?) I'll work on the NMU patch tonight and add it to #418637. If I don't hear from you, I'll assume I can upload the NMU to the delayed queue 7 days from when the patch is added to #418637 and I'll mark this bug as blocking the bug fixes for deb-gview. I would MUCH prefer if you could fix this earlier or at least accept this offer to be co-maintainer for libarchive - this bug is delaying the update to deb-gview which contains useful functionality and bug fixes. Please let me know ASAP. [0] http://www.gnu.org/software/libtool/manual.html#Updating-version-info -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp2jdo1c5_8e.pgp
Description: PGP signature