On Mon, Oct 04, 2004 at 07:56:06AM +0200, Andreas Barth wrote: > * Steve Langasek (vorlon@debian.org) [041004 00:40]: > > On Sun, Oct 03, 2004 at 02:53:57PM -0400, Joey Hess wrote: > > > We would still list everything in recommends. There were many reasons why I > > > moved all contents of these tasks to the recommends field, including: > > > - Getting the packages into testing, which was previously apparently > > > impossible. > > > - Avoiding the common problem with task packages that if you remove > > > one package in the task, you have to remove the task package as > > > well, since its dependecies are then broken. > > > - As part of the phasing out of the old reason for the old-type task > > > packages; selection of the packages in these tasks are not handled at > > > the tasksel level by recommends fields ayway, but by tasksel package > > > lists in the education-tasks package. The new task packages will > > > mostly be useful for post-install sysadmin and upgrade purposes. > > The first two of these advantages would no longer be present if britney > > treated Recommends the same way as it treats Depends, which is why I > > ask. > I think missing Recommends should _not_ be tracked by britney, but > "just" being RC-buggy (about the same level as missing build > dependencies). <shrug> Britney's job is to help make it easier for us to ensure that testing is in a constantly releasable state. I think it *should* keep as many RC bugs out of testing as possible; as shown by many recent 11th-hour bug submissions, we haven't been very successful at keeping other kinds of RC-buggy package relationships out. If britney can be used to address these errors proactively, I believe it would be beneficial; the question is whether it actually *can*, or if requiring fulfilled build-dependencies throughout a development cycle would make testing too rigid. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature