On Fri, Oct 03, 2003 at 02:59:21PM +0200, Björn Stenberg wrote: > > Yep, and libxml2 is also a dependency of libxslt. But of course, > > neither of these are packages that need direct attention; the one is > > held up waiting for the other, which is only waiting because it's too > > young. It's the related packages that need to be examined and put in > > order (by removals or NMUs), and there's no good way to figure out right > > now which packages those are, short of digging through the dependency > > tree (or running simulations).
> I don't quite follow you here. What exactly would you like to see? Which > packages are waiting for the libxslt/libxml2 knot to be untied? That's > available here: Not which ones are waiting, though that's useful information. What we need is to be able to find out what packages depend on things like python2.3, but are *not* in the list because they themselves are not valid candidates. Usually when you have a lot of packages waiting on a single package before they can move into testing, there's a hard (as opposed to soft) transition involved which requires lots of packages to all be ready for testing at once. Your pages don't really identify those other packages which will need to be worked on. Currently, that information is available in raw form from http://ftp-master.debian.org/testing/update_output.txt.gz if the package at the base of the dependency tree is a valid candidate, and there's no place to easily get that information if that package is *not* yet a valid candidate. What would be nice is for developers to easily find out what else *will be* a blocker, so that we don't have to repeat a 10+ day cycle for every package in the group that's buggy. And I say it "would be nice". This would be a difficult script to write, and probably even more difficult to run due to the amount of information that has to be processed. Right now the best system we have for getting this information is human traversal of dependency graphs, plus some simulation scripts which (AIUI) let us examine clusters of interest on a case-by-case basis. This isn't great, but it's not horrible either. > > Well, if you want to write a script that can trawl the dependency graphs > > and identify work-needed packages within a cluster... :) > Could you tell me in more detail what you mean? I'm not very > experienced with the Debian release process, so I am not familiar with > the nuances. I already trawl the dependency tree, what information > would you like to distill from it? (I.e. define "work-needed packages" > and "cluster".) "work-needed packages" refers here to those packages which are not valid candidates for testing because they are themselves buggy (either they have open RC bugs against them, or they are uninstallable/unbuildable/out-of-date, which is typically an unfiled RC bug). "cluster" refers to a group of packages which are so tightly interrelated (due to versioned depends, library soname changes, etc.) that they must all move into testing at the same time. > A hypothetical example would be good, to get me on the right track. Hypothetical example: 29 packages wait on (151 packages are stalled by) libxml2. This package is too young, and should be a valid candidate in 8 days. Suppose that the libxml2 source package provided not only the libxml2-python2.3 binary package, but also a libxml2-python package that depended on python (>> 2.3). If that were the case, then even after libxml2 became a valid candidate in its own right, it would still be held up by the python2.3 transition. Cheers, -- Steve Langasek postmodern programmer
pgpIg3Jv5N8q0.pgp
Description: PGP signature
