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? That's the point about the SONAME change being spurious - there is no v2 of libarchive.so at a binary level. The library hasn't changed ABI so there was no need to create a libarchive2 upstream or in Debian. The symlink from the revised patch implements this - it allows packages built against libarchive.so.1 to run against libarchive.so.2 simply because libarchive.so.2 is compatible (and thereby unnecessary). > > 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 Etch if GNU libtool conventions had been > > followed in the SONAME. > > Well, again, it doesn't seem impossible to fix the tar manpage > problem. Even failing that, if everything that uses libarchive is > simply rebuilt sometime between now and the release of lenny, and > libarchive2 conflicts and replaces libarchive1... where is the > problem? The upgrade and builds should all work fine. The problem of the manpage just highlighted the underlying problem that the SONAME bump was not necessary and if that had not been made, the manpage problem would not have been a problem in the first place and none of this would have happened. The manpage issue is not the real problem, that is the spurious SONAME bump causing a transition that is simply unnecessary. When I came across this original bug, I wanted to be able to install the updated libarchive-dev so that I could migrate deb-gview to what I assumed was the libarchive2 ABI/API. I was surprised to find that there was no new ABI, it was the same as libarchive1. > > What is your proposed fix for this blocking bug? > > It seems that the sensible thing is to make libarchive2 conflict and > replace libarchive1, and to have anything that was still built against > libarchive1 be rebuilt before lenny is released. That looks like > approximately 4 packages. > > -- John Well, the revised patch means that packages will not need to be rebuilt (because no SONAME transition has actually happened) but those that are rebuilt for their own reasons will need a versioned depends. If and when libarchive does break the ABI, libarchive3 will be necessary and the manpage will need to either be in a separate package or have a Replace: setting. libarchive1 now conflicts and replaces libarchive2 by providing libarchive.so.2 inside libarchive1 and has the symlink to create libarchive.so.1. None of this would have been needed if upstream had a sensible SONAME policy. It would be good if upstream could be asked to implement a sane versioning system before libarchive3 arrives, whenever that may be. ;-) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpK6uEtpyknB.pgp
Description: PGP signature
