Re: Use of the Build-Conflicts field
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
Reply to: