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