Ian Jackson:
Package: dpkg Version: 1.22.13 Control: block 1092190 by -1Hi. (Firstly, I should say thank you very much to Niels Thykier for your work on Rules-Requires-Root. Tidying this up is a big job which you've been doing very well. Speaking personally I have really appreciated the interactions I've had with you over my packages. Now, though, I'm afraid I come with the change request:)
You are welcome. I appreciate your openness to the R³ changes. Especially since I filed bugs for a couple of your packages prior to the MBF to get the ball rolling.
It seems likely to me that there will continue to be packages in the wild which this behavioural change will break - particularly including packages not part of Debian, packages from old Debian release, and perhaps whole derivative distros. > In order to allow us to build old packages with new tooling, or out-of-distro packages, or whatever, I think dpkg-buildpackage should have a way to request the previous (bookworm-and-earlier) behaviour.
This may have merit on its own. Though for the purpose of dgit's test suite, I would like to challenge the rule-invocation-tracking bit from #1092190 here:
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.
The `dh` package even added support for self-recursing into explicit `build` targets as a part of compat 9 align itself with expected practices (I think it was https://bugs.debian.org/629139)
Therefore, I would like to approach this from what are these rule-invocation-tracking test *expected* to validate and how are they doing it?
[...] Could we please have a command line option to just change the default, so that trixie's dpkg-buildpackage can be used in circumstances where bookworm's would have worked ? > We should probably consider whether we want to make this behaviour controllable by an environment variable, as well. That way a program which is trying to work with various different dpkg-buildpackage version (eg a CI job that runs with different images) wouldn't have to probe for the option. I'm filing this bug as "normal" because I think that's warranted by the behavioural regression for out-of-Debian users. Thanks for your attention. Ian.
I will leave this part to Guillem as the dpkg maintainer, since he will be maintaining that feature.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
