On Mon, Aug 04, 2003 at 01:37:43AM +0200, Thomas Viehmann wrote: > Chris Cheney wrote: > ... > > for example libexif8 was removed by Christophe Barbe and replaced by > > libexif9. Guess what that does... any package which depends on libexif8 > ... > > not be removed from the archive until no other packages still depend on > > it. > Well, if it's uninstallable for a couple of days, does it matter that much? > My guess is that while it would be nice to have other ways dealing with this, > your suggestion would create a ton of problems for maintainers to have to follow > too many old versions of their packages. The problem, which is a very real one, is this: - large application at the top of the dependency change is uploaded. - library it depends on has an soname bump before the application makes it into testing. - bug is filed against the application, because it's now uninstallable on sid. - recompiled application is uploaded; testing counter resets. That said, I don't think Chris's recommendation is the right one. In one sense, the status quo results in a strong incentive for application maintainers to "trim the fat" from their dependency trees. Moreover, requiring library maintainers to maintain multiple copies simultaneously seems rather extreme, for issues that really only apply to a subset of packages. I think a better approach would simply be to regard application uninstallable-in-sid bugs as non-RC for testing purposes. Since the testing scripts will already refuse to process new libs that render applications uninstallable, the only impact here will be that certain packages will be uninstallable on a new, completely pristine unstable system -- which, frankly, is not a significant concern of mine. (Putting both testing and unstable in sources.list works just fine, IME.) Tagging such bugs appropriately and ignoring them until after the application makes its way into testing would probably serve our release process better than worrying about uninstallability problems caused by versions of packages which are themselves not yet release candidates. -- Steve Langasek postmodern programmer
Attachment:
pgpFgnaxvuJCN.pgp
Description: PGP signature