On Sun, 02 Oct 2022 at 10:16:00 +0200, Sebastiaan Couwenberg wrote: > On 10/2/22 04:23, Adam Borowski quoted Policy: > > # "clean" > > # Only the "Build-Depends" and "Build-Conflicts" fields must be > > # satisfied when this target is invoked. > > Shouldn't Build-Depends-Indep be considered as part of Build-Depends?
I think that would defeat the purpose of splitting B-D, B-D-I and B-D-A. A common reason to use B-D-I is that building documentation needs a relatively "heavy" tool like doxygen, gtk-doc or TeX, which is time- and space-consuming to install and harder to satisfy during architecture bootstrapping. If we required B-D-I to be satisfied for clean, then that would mean the documentation tool would be required when running dpkg-buildpackage -B, which expands to somethng similar to debian/rules clean debian/rules build-arch debian/rules binary-arch That would have the same practical result as moving everything from B-D-I to B-D. > Packages that only build Architecture: all binary packages tend to use > Build-Depends-Indep. Policy is quite clear about that being a bug. I think a better rule of thumb for maintainers in a hurry would be: if you don't have time to think about which dependency list is the right one, and preferably test the result (with a source-only build like Adam has been doing, a --build=all build, and a --build=any build), then the safe option is to put everything in B-D. smcv