On Mon, Apr 16, 2007 at 08:11:19AM -0500, John Goerzen wrote:
If the libarchive2 package had been installable alongside the
libarchive1 package, this would have not been a problem but it would
still have been the wrong thing to do, IMHO. libarchive 2.0.25 could
possibly have made it into
On Sun, Apr 15, 2007 at 10:02:28PM -0500, John Goerzen wrote:
I have had a chance only to skim the discussion about this, but...
I think it would be unwise for Debian to arbitrarily use a different
soname here than upstream and, presumably, everybody else. It can only
hurt binary
On Sun, 15 Apr 2007 22:02:28 -0500
John Goerzen [EMAIL PROTECTED] wrote:
I have had a chance only to skim the discussion about this, but...
I think it would be unwise for Debian to arbitrarily use a different
soname here than upstream and, presumably, everybody else.
It's not arbitrary - the
On Mon, Apr 16, 2007 at 12:33:07PM +0100, Neil Williams wrote:
It's not arbitrary - the SONAME change has already broken compatibility
within Debian.
There is only on -dev package for either libarchive1 or the useless
libarchive2 so rebuilding is not affected, as soon as libarchive-dev is
On Mon, 16 Apr 2007 08:11:19 -0500
John Goerzen [EMAIL PROTECTED] wrote:
It can
only hurt binary compatibility.
Vorlon's suggestion of a symlink prevents that.
I'm not so sure. Wouldn't binaries built on Debian want a library v1,
which wouldn't work on systems that provide v2?
These are the changes that I propose to make in an NMU for libarchive
to revert the SONAME change to restore libarchive1 and turn libarchive2
into a dummy package.
The interdiff -z is very large (1.8Mb) because the changes have to patch
configure.in which causes configure to be regenerated and
I have had a chance only to skim the discussion about this, but...
I think it would be unwise for Debian to arbitrarily use a different
soname here than upstream and, presumably, everybody else. It can only
hurt binary compatibility. I have not had the chance to ask upstream
about it, and it
7 matches
Mail list logo
