Niels Thykier writes ("Re: Bug#1092193: option (or env) to request <=bookworm
r-r-r behaviour"):
> Ian Jackson:
> >> dgit's test suite uses some rule-invocation-tracking test packages to
> >> see which targets get invoked by various build modes. (This is
> >> necessary to make sure that dgit's invocations of various build tools
> >> DTRT.)
>
> The existing expectation from Debian packaging is that the package is
> expected to recurse into the `build` target on its own as needed if you
> call `binary` directly. Therefore, I think the rule-invocation-tracking
> tests on its own is "buggy" (makes invalid assumptions) here.
tl;dr: This consideration is indeed why I don't think the dgit test
suite is a good motivation for the change I'm requesting in dpkg, and
why I didn't make such a connection in the reasoning in my
src:dpkg bug.
Longer answer:
Yes, I see your point. However, what these particular tests are
trying to check is precisely which build targets get invoked by dgit's
own build subcommands. Ie, it is testing the behaviour of build
tools: the way that dgit drives (say) pbuilder which then drives
dpkg-buildpackage. I think an end-to-end test like this is probably
the best way to do that, even if it means updating the test cases
every decade or so :-).
Separately, though, I do think the compat option I am proposing for
dpkg-buildpackage makes sense for the reasons I've explained - ie, for
the benefit of old and out-of-Debian packages (ie for real packages,
not weird test packages like in dgit:tests/). Without such an
option, we risk digging some users into a hole.
Given that, it seemed most sensible to have the conversation about
that first, since if that option is going to be provided it can be
conveniently (ab)used by src:dgit's tests. If that option is not
going to be provided, I'm sure we can take another approach in the
tests. In that case we'd unlink the two bugs.
> Therefore, I would like to approach this from what are these
> rule-invocation-tracking test *expected* to validate and how are they
> doing it?
To directly answer your question, here is what I wrote in the commit
message in 2015 (cfec91c99eff):
Test suite: Provide tests which check that all our various build
operations run the right targets as expected (ie, that we are
massaging the arguments to dpkg-buildpackage, and suppressing our
clean target, etc., correctly).
TBH I consider it unfortunate that dgit has all these build wrappers.
Debian really doesn't need more layers of build wrappers. So I would
like to abolish them. But the reasons which necessitate their
existence (which are a whole other topic) don't seem to be going away
soon. It's possible that further along the git transition we'll be
able to clean this up but that's well beyond my planning horizon.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
