dpkg-source to automatically add a Testsuite field

[guillem@debian.org (Guillem Jover)]

Hi!

On Mon, 2014-07-07 at 13:19:41 -0300, Antonio Terceiro wrote:
> On Sun, Jul 06, 2014 at 06:35:47PM +0200, Guillem Jover wrote:
> > Reading the spec [S], it seems to me that the file can be empty, as it
> > states ?This is a file containing zero or more RFC822-style stanzas?,
> > so the code cannot do any sanity check, like checking if the file
> > contains one stanza with a Tests field. So it will only check for the
> > file presence.
> > 
> >   [S] <https://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=doc/README.package-tests.rst;hb=HEAD>
> > 
> > I've queued a patch doing exactly that for dpkg 1.17.11. If there's
> > any known reservations with that, please speak up.
> 
> How will it handle an existing value in that field? In the future, we
> might have other forms of test suite, thus requiring different items in
> the Testsuite: field.  What happens when there is already
> 
>   Testsuite: foo
> 
> and dpkg-source detects the presence of debian/tests/control? Will it
> merge `autopkgtest` into the list, or will it replace the existing
> value?

Ah indeed, here's the current behavior:

The field is parsed as a comma-separated list of values (as per the
spec). If the debian/tests/control file is present then the value will
be added to the list. The values will always get emitted in alphabetical
order as a comma-separated list, any dupes squashed, so that the output
is reproducible. Unknown values are emitted untouched.

If the field contains ?autopkgtest?, but the debian/tests/control file
is not present, then a warning will be issued, and the value preserved,
as in ?the maintainer knows better!??. But maybe it is actually better
to warn and just trim the ?autopkgtest? value?

Does this resolve your concern?

Thanks,
Guillem