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 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. Name changes of library packages: - limit the possibility of partial upgrades from stable to stable+1 - cause more work for anyone wanting to distribute third-party packages using that library and targetting both stable and stable+1 - complicate the upgrade path between stable releases. In the pathological case of a renamed library that conflicts/replaces a previous version (which has been necessary with every recent Debian release due to compiler ABI transitions), this makes the upgrade path not just computationally expensive, but impossible for the existing package management tools to calculate at a single go, requiring a lot of extra effort to identify an upgrade path and address it in the release notes. So unnecessary library package renames should absolutely be avoided, particularly because of this last issue. Even if libarchive doesn't have enough reverse-dependencies (now) to make it seem like an issue for stable upgrades, these problems do have a cumulative effect, and it's simply best practices to make library updates as non-intrusive as possible. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
