implicit debian/tests/control files
On Wed, Sep 10, 2014 at 09:33:21PM +0200, Martin Pitt wrote:
> Niko Tyni [2014-09-10 19:58 +0300]:
> > This brings me to a more generic question: should we treat these
> > synthesized test control files in autopkgtest as a temporary
> > solution while individual packages grow control files of their own,
> > or is this a sustainable solution of centralizing the test logic?
> Admittedly these dynamically generated control files are a bit against
> the spirit of DEP-8 to have an explicit test control. However, I think
> it's not too bad as the benefit of not having to change 3.000 source
> packages all the time is just immense. The one thing I'd like to add
> to the source packages is an "XS-Testsuite: autopkgtest" field though,
> so that we can stop maintaining hardcoded whitelists at some point
> (but from my POV it's ok if that takes several years even).
While I certainly agree about the benefits, I'm worried about other
consumers of debian/tests/control, which would have to reimplement the
implicit control files. There's at least sadt(1) in devscripts that I
> But as I said, I don't think this should be designed in a hurry.
Very much agreed; apologies for the premature poking. We should have
that discussion in the relevant bug report (#759753).
> But I understand that with the current fully dynamic method this isn't
> very urgent, or am I missing something?
There's no real urgency, no. We can, and probably should, just stop
including the control files for now and rely on the dynamic ones.
However, I'm somewhat against including the Testsuite headers without a
debian/tests/control file, as that could actually break other (current
or future) implementations.
Similarly, for packages that don't pass their tests and need tuning,
I'd like to add a control file as part of the tuning process even if it's
unmodified from the default one. (We have some additional test-specific
tuning knobs that don't need modifying d/t/control.)
Niko Tyni firstname.lastname@example.org