On Wed, May 27, 2026 at 10:19:07PM +0200, Simon Josefsson wrote:
Jérémy Lal <[email protected]> writes:
running a test suite during build is something that feels more and more
useless, given debci.
While I think building with 'nocheck' on buildd's at some point in time
would be reasonable,
To do that, I think we'd need a formal requirement that any package
supporting the nocheck profile must have autopkgtests that run
equivalent or stricter tests, and some way to enforce that. I'm not
sure how to do that ...
In the Python ecosystem, we could probably at least start to statically
analyze the packages that use autopkgtest-pkg-pybuild to check whether
this is the case, but there are a lot that don't for one reason or
another. There are also quite a few odd cases where we have tests that
only work properly at build time and don't work in autopkgtest (at least
not with our current setup for them), such as:
https://salsa.debian.org/python-team/packages/pylint/-/blob/debian/4.0.5-1/debian/rules?ref_type=tags#L39-L44
So I think if we wanted to do this in practice and at scale, it would
have to be done a bit like Rules-Requires-Root. We could invent a
control field that says that a package can safely be built with nocheck
without losing coverage, as long as the system as a whole promises to
also run autopkgtests later.
I'm not sure that this is something I would personally want to opt into
as a maintainer, though. The trade-off is between buildd time and the
likelihood of delivering more broken things to unstable. Buildd time
doesn't typically seem to be as contended as autopkgtest worker time,
and shipping broken things in unstable does have a cost: as well as
those users who use unstable, it increases the risk that other packages
will be built against broken packages, which can be difficult to
untangle.
It seems to me that improving the bootstrapping situation for cases
where loops can be broken using nocheck would be a safer way to go. As
Paul suggests, Debusine can at least allow users to submit build
requests with arbitrary build profiles and have them built on all the
architectures we support, although it's a bit awkward right now (it's
only supported in the sbuild workflow, not in the higher-level
debian_pipeline workflow, so you wouldn't get most of the QA tasks). If
somebody wanted to try to specify what's missing there then that would
be worthwhile. There might be some other tools lying around that I'm
unaware of too.
--
Colin Watson (he/him) [[email protected]]
