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

Re: Which packages will hold up the release?

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

"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.

Steve Langasek
postmodern programmer

Attachment: pgpfTYRYNCcTs.pgp
Description: PGP signature

Reply to: