[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Please consider a binNMU on reprepro due to libarchive transition.

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

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

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.


> 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

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.



Neil Williams

Attachment: pgpAX0p9EMwGF.pgp
Description: PGP signature

Reply to: