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

Re: libraries being removed from the archive

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

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

Reply to: