Steve Langasek wrote:
> What's hard to see at a glance is how large collections of packages are
> interrelated in their dependencies.  Many packages that you *don't* use
> may be having a direct effect on the packages you *do* use as a result
> of their bugginess.  I'd like to be able to make as much of this
> information as possible available to developers, so they can dig into
> some of the larger package knots according to their interests rather
> than it being exclusively the domain of the RM & assistants.

I'm interested in helping with this. My "why is X not in testing yet" script 
attempts to identify some hot spots, in the form of a few crude toplists:

  http://bjorn.haxx.se/debian/toplist.html
  http://bjorn.haxx.se/debian/stalls.html

The first sorts packages according to which package has the highest number of 
other packages directly depend on it. Top-3: python2.3, kdelibs, qt-x11-free.

The second sorts packages according to which package "stalls" the greatest 
number of other packages, via dependencies in more than one level. Top-3: 
python2.3, libxml2 and libxslt.

I'd appreciate ideas and suggestions how to improve this and create other 
information digests that can help developers find and choose areas to work on.

-- 
Björn


Reply via email to