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

Re: Bug#273734: education-common: con't fulfill the Recommends on !i386

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

Reply to: