On Sat, Nov 03, 2018 at 03:42:20PM -0700, Russ Allbery wrote: > In a way, I don't think this goes far enough. Build-Conflicting with > something installed by debhelper would be incredibly painful and would > basically require the package be built in a chroot.
I'm not sure what do you mean by "painful" here. In this case, a Build-Conflicts would have told sbuild to uninstall automake during the "install build-dependencies stage", which is not painful at all. The real pain comes from not having a build-conflicts at all (because in such case there was a FTBFS). > In this particular case, it also seems unnecessary. [...] In this case, it was unnecessary, yes. The maintainer solved the problem by calling automake-1.11 by its versioned name. But as far as this was not done yet, the package had an undeclared build-conflicts. Anyway, this was the case that made me think about the language used in policy. The package (as it was) "required" in an absolute sense not to have automake installed as much as it "required" to have their build-dependencies installed. That's why "can" or "may" seemed a little bit strange for the wording to me. Maybe the relevant paragraph in policy is this one instead: If build-time dependencies are specified, it must be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (including any implied relationships). To follow with the previous example, does this paragraph imply that if you call automake by "automake" and you build-depend on automake-1.11 then you should use a build-conflict? I don't think so, because the "with only [...]" part suggests the completely minimal chroot approach to building packages. Thanks.
