So, I've only had a desire to use the build-conflicts field once in my time doing Debian packaging, but that one time it was such the right answer that I was really glad the field is there.
I was packaging Moonshot, a GSS-API mechanism based on EAP. It depends heavily on the underlying capabilities of the GSS-API infrastructure, and has autoconf tests to detect what capabilities it needs. There are several gss-api implementations in Debian. The library depends on the one it wants, although you could easily choose for local needs to build against Heimdal rather than MIT if you liked. You shouldn't upload that package to the archive unless we've made a change to what we prefer for Moonshot. But there's one gss implementation that simply won't work: libgss-dev. It's antequated (or at least was) and missing critical features from modern GSS-API. If you try, you'll get obscure errors about missing capabilities. Build-Conflicts provided a way to give a very valid Debian-specific error describing what went wrong if you tried to build a debian package in that environment. Especially when I was doing both NFS and Moonshot builds, it really helped me avoid shooting myselfg in the foot. It also helped others. Unless we're going to go so far as to forbid developers from doing builds outside of chroots, it's useful to express this sort of thing. --Sam
