I think "make tools/widl/widl" should generally do the right thing, without building all of Wine.
Yeah, I thought that it would still require a ton of build dependencies for Wine, but it ended up not requiring anything else when using `--without-x --without-freetype`. So it's probably a better solution.
I'd also be inclined to suggest building a specific widl version like 3.20, instead of building what happens to be in Wine git when creating the image. There may be a similar consideration around targetting unstable instead of a specific release.
Ok, I don't have a strong opinion, so just went with Wine 3.21 (given that 3.20 proved to be too old). WRT the Debian version, I am somewhat less convinced, mostly because of the Mesa drivers. As I understand it, llvmpipe is evolving quite quickly, so tracking a more recent Mesa version might me more helpful for development. OTOH it's also valuable to check that things didn't break for released software. Maybe this is just a good reason to test on different Debian versions. One could say that in general more variations you test with, more useful the CI is; and that current pipelines are still quite fast, so we still have a few points to spend before the whole thing becomes unwieldy.
Let's say that I'll go with bookworm for the moment, and leave further experimentation for the future.
Of course widl is also available in the wine64-tools package on Debian. It's a bit unfortunate that this package depends on libwine-dev -> libwine, which ends up pulling in most of Wine's dependencies anyway. Ideally that would be improved on the Debian side, but in theory we could at least do better for the packages hosted at dl.winehq.org...
Initially I used the Debian package, but desisted for precisely that reason. Given that the current situation seems acceptable for us, I won't concern myself with packaging issues for the time being.
ACK to everything else.