Hello Johannes, On Fri 21 Dec 2018 at 08:18pm +0100, Johannes Schauer wrote:
> could you check with the autopkgtest maintainers/developers about this?
Instead of doing this, I just looked at the code, of both autopkgtest
and autodep8.
I can confirm these two facts:
1. autopkgtest invokes autodep8 if d/tests/control is missing.
Quoting README.package-tests.txt,
There are groups of similarly-structured packages for which the
contents of ``debian/tests/control`` would be mostly identical, such
as Perl or Ruby libraries. If ``debian/tests/control`` is absent,
the ``autodep8`` tool can generate an automatic control file. If
installed, ``autopkgtest`` will automatically use it; this can be
disabled with the ``--no-auto-control`` option.
2. autodep8 does not require the Testsuite: field to be present. It
chooses whether to generate d/tests/control based on arbitrary
heuristics. For example, for elpa-* packages, it generates a
d/tests/control when either an appropriate Testsuite: value is
present, or it actually finds runnable tests (it greps the source
code of the package).
To summarise the bug I consider sbuild to have:
autopkgtest can run many tests suites when d/tests/control is not
present, by invoking autodep8, but recent sbuild shortcircuits that by
refusing to invoke autopkgtest when d/tests/control is absent, even when
the user has passed --run-autopkgtest to sbuild.
In the absence of d/tests/control, the only way for sbuild to be sure
whether autopkgtest is able to run the tests would be to duplicate the
logic in autodep8 or have sbuild invoke autodep8; this seems to me like
a layering violation. I think that sbuild should revert to the old
behaviour of always invoking autopkgtest when the user requests it, and
letting it decide whether to skip.
I'm sorry that I did not include all this information in my original
report. Thank you for your patience.
--
Sean Whitton
signature.asc
Description: PGP signature
