On Tue, Oct 07, 2003 at 05:23:32PM +0200, Björn Stenberg wrote: > Steve Langasek wrote: > > 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. > Thank you. Some followup questions: > 1) How are meta packages handled, such as libz-dev that libxml2 > depends on. There is no package or binary with that name listed in > Sources. The testing scripts (barring any bugs) check to make sure that a given candidate package would be *installable* on a system composed only of testing packages. This means that it treats virtual packages the same way that dpkg does on install: by looking for available packages that Provide: the needed virtual package. > 2) How is meta package versioning handled? The gcc-defaults package, > version 1.9, is the only package providing the gcc binary (without > -version suffix) of which many packages require version >= 2.95. The term "metapackage" is a gratuitous label, here. There is a real binary package (as opposed to a virtual package) in the archive named "gcc", which comes from the gcc-defaults source package; and its versions are handled just like those of any other packages. -- Steve Langasek postmodern programmer
Attachment:
pgpekYuPiWOzv.pgp
Description: PGP signature