Changes to NEW for source-only uploads

[Ansgar Burchardt <ansgar@debian.org>]

Hi,

to allow source-only uploads we need a few changes to NEW unless we want
binary-NEW uploads from every buildd (which we don't want to reject). I
think we can manage with using the Package-List field in the source
package:

Using Package-List for NEW
--------------------------

For packages with a Package-List field:

a, If the source has no override, then the package is NEW.
b, Otherwise build a list of packages built on any architecture in the
target suite. If any of those has no override, then the package in
binary-NEW.

Suggested Priority and Section for new binary packages are taken from
the Package-List field.

Fallback for old packages w/o Package-List
------------------------------------------

As a fallback for sources not having a Package-List, dak would assume
all packages in the Binary field are built on architectures in the
archive. Section and Priority for new binaries would need to be filled
in by the person processing the upload.[1]

This might cause false-positives for, for example, kernel uploads in
squeeze-lts as it lists m64k binaries.

Alternatively, assume there are no binary-NEW packages and let the
buildd uploads hit NEW if needed. (But this should be a suite option so
it doesn't happen for unstable.)

The fallback is needed for uploads to oldstable.

  [1] This is one case where not requiring overrides would make life
      easier.

NEW in dak2
-----------

For dak2, I would like to do more drastic changes to NEW: overrides and
NEW should be decoupled to allow archives without a NEW queue and/or
without overrides.

My idea for NEW there is to have a table listing which sources are
allowed and which binaries these may produce. With this one could also
make takeovers go to NEW (to avoid takeovers by accident).

There should be options to configure if
a, NEW is required,
b, binary-NEW is required, and
c, binary-NEW-for-takeovers are required.

Overrides should be optional as well. Nothing needs to change how we
handle them (except for implementation changes). I'm also wondering if
one shoud make overrides more general (to allow changing other fields as
well) and/or to make overrides matching the package data disappear
automatically.

Ansgar