Re: How are things going?

[Guillem Jover <guillem@debian.org>]

On Thu, 2006-09-28 at 16:51:33 -0700, Steve Langasek wrote:
> On Thu, Sep 28, 2006 at 03:59:14PM -0400, Joey Hess wrote:
> > Steve Langasek wrote:
> > > Since "Breaks field" here means "doesn't complain about the Breaks field",
> > > rather than "honors the Breaks field", these changes look ok.

Argh, I should have corrected this one, sorry. From the changelog:

  * Add initial support for the Breaks field, by parsing but rejecting it.

> > > As far as *implementing* Breaks, I don't think a new feature of that
> > > level should be introduced during a freeze.

I'd feel really unconfortable introducing full support at this time.

> > Couldn't it be potentially dangerous to have a dpkg in a released
> > version of Debian that silently ignores Breaks? It seems it would both
> > allow for much foot-shooting by anyone who tries to install packages
> > from another source that use Breaks, as well as prevent us from using
> > Breaks in any packages in etch+1, since upgrades won't work.

This should not be the case.

> Hmm, good point.  The logical consequence of supporting Breaks is that we
> will start to see packages that use Breaks instead of Conflicts, so
> silently ignoring the contents of the Breaks field will result in packages
> being co-installed that should not have been.

> So indeed, I think we want Breaks support to be all or nothing.

No, I'd say we want partial then full support. And we definitely want
that the dpkg in the next release understands the field and rejects
it, so that we don't get an upgrade path where suddenly the system has
got unsatisfiable dependencies due to dpkg not understanding the field
previously.

There's two ways to introduce it that I can think of now, but I'd opt
for the first one, otherwise we'll need to wait a lot for this.

Fast:

  * etch
    - dpkg parse but reject.
  * etch+1:
    - dpkg full support.
    - require to upgrade dpkg first from etch to etch+1.
    - packages using the field in the archive (not the ones that dpkg
      (pre-)depends on though).

Slow:

  * etch
    - dpkg parse but reject.
  * etch+1
    - dak disallows packages in the archive with such field.
    - dpkg full support.
  * etch+2
    - dak allows packages in the archive with such field.

regards,
guillem