Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

[Richard Braakman <dark@xs4all.nl>]

Are the -Conflicts headers really necessary?  So far I have not been
able to think of a use for them, and they complicate the task of the
build daemons ("install everything needed to build this package")
unnecessarily.  We've already seen with binary dependencies that
the Conflicts relationships create the most difficult problems.

If package foo has Build-Conflicts: bar, it means that the *presence*
of bar will prevent foo from building correctly.  I consider that a
bug!  Adding support for this would condone such bugs.

I propose that the -Conflicts headers be dropped, unless there is
an example of when they would be good and useful.  I've already
considered a few:

  - Problem: There are two conflicting development environments (let's
    call them tk40-dev and tk41-dev :-), and foo needs the right one.
    Solution: foo declares a Build-Depends on tk41-dev, and tk41-dev
    conflicts with tk40-dev.
  - Problem: Package foo needs debassistant >= 0.8 to build, but
    will not work with debassistant version 0.93 which has a horrible bug.
    Solution: foo declares
          Build-Depends: debassistant (>= 0.8),
                         debassistant (<< 0.93) | debassistant (>> 0.93)

Is there any case where one would want a Build-Conflicts?  Allowing
them will complicate all the code that deals with build dependencies,
whether they are used or not.

Richard Braakman