Broken dependencies in universe

[Keith Irwin]

On Fri, 2004-10-22 at 12:44 -0700, Matt Zimmerman wrote:
> On Fri, Oct 22, 2004 at 12:11:42AM -0700, Ryan Thiessen wrote:

> > While upgrading from Debian Woody to Ubuntu Wart I came across some
> > odd problems with dependencies.  It seems that certain packages are in
> > the Warty universe but with broken dependencies.  For example, the

> It looks like it was probably broken in Debian unstable at the time that we
> froze, and the nature of universe is that it doesn't receive the QA
> attention that main does.

> There's no need to remove them when the
> underlying problem is usually easily fixable if someone investigates it.

Is there a way we can volunteer to track down and offer fixes for our
favorite packages?  For instance, I'd love to get the SBCL and CMUCL
packages working (the common lisp compilers), but have no idea who to
contact about a fix.

I downloaded the source I found in universe and tried to compile and
found some problems compiling the older lisp with a newer compiler, but
have no idea what to do about it.  I suspect that the reason sbcl didn't
compile is because it needs another lisp (or itself) to exist in the
build environment in order to compile itself.

This means that I'd have to know how it's being built, not just what the
error was. ("DepWait."  Was it waiting for itself?)

Might there be a way for us to help in this area?

Keith

> > It seems more logical to me that if a package does not exist in Ubuntu
> > universe, every application that depends on that package should not be in
> > universe either.  Having broken packages in the repository just seems
> > tacky and worse than not having the packages available at all.  Or is
> > there a reason I'm not aware of why broken packages have a reason to exist
> > in the repository?
> 
> "tacky" or not, many of the uninstallable packages in universe are due to
> other packages which fail to build, and if they were fixed, these packages
> would become installable.  There's no need to remove them when the
> underlying problem is usually easily fixable if someone investigates it.
> 
> -- 
>  - mdz
>