Ian Jackson:
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.[...] 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.
Indeed, I have no concerns about discussing the compat option on its own merits. I do not really have a dog in that race since my sphere of interest is primarily about packages aimed at Debian and I am not maintaining the code affected (to be as frank as possible).
So I will leave that discussion between Guillem and you.
[...]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.
I am unsure if it is deliberately aimed at testing this praticular implementation detail of dpkg calling d/rules build separately or not. Like is there ever a case where dgit wants to call "build" without "binary"?
If it is deliberately testing dpkg calling d/rules build separately from d/rules binary, then it is a question of test philosophy in dgit, which I should step out of since I am not a dgit maintainer.
If it is not about that particular implementation details (but instead ensuring clean is not run), then I think something like:
"""
build build-arch build-indep %:
dh $@
"""
would be more robust in the test with only the d/rules of the test being
slightly more unsightly (example assumes debhelper compat 9+ semantics).
But again, if the test is also about doing implementation detail testing of dpkg, then my proposal here is not helpful
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
