Bug#824495: debian-policy: Source packages "can" declare relationships
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.
Reply to: