Sam Hartman writes ("Re: Use of the Build-Conflicts field"): > Especially when I was doing both NFS and Moonshot builds, it really > helped me avoid shooting myselfg in the foot. > It also helped others.
Right. Your example seems perfect to me because it demonstrates nicely the difference between "having this package in your build environment will cause a different .deb to the one the Debian maintainers would intend to ship to all of Debian's users" and "it will make things actually go wrong". Building a nonstandard .deb is not wrong, it's just nonstandard :-). We already pretty much insist that builds *for upload* are done in a very controlled way (ideally on buildds) and that's fine, and good, and should lead to the standard binaries that we expect. ISTM that the purpose of Build-Conflicts is not to affect the standard sbuild-style builds in Debian (which already have a much more predictable build-dependency resolver), but to (i) assist developers and users doing ad-hoc builds in less controlled environments (ii) perhaps also to provide useful info for Debian derivatives. > 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. Absolutely. I don't think anyone here is really arguing against the value of Build-Conflicts. The question Sean asked was whether a lack of an applicable Build-Conflicts was considered RC; and the answer seems to be that people think it isn't. I also expect that subject to the constraint that this won't generate RC bugs, people will be generally happy to have policy write down roughly what the criteria are for putting in a Build-Conflicts. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.