> 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.That's not really true. The parsing is nearly the same, and it's no trouble in sbuild to deinstall packages as that's needed anyway after the build. I guess the negative deps (as I have called them in sbuild) make about 5 lines of code. > We've already seen with binary dependencies that the Conflicts > relationships create the most difficult problems. But it's something different here... It's really trivial to temporatily uninstall a package and reinstall it later. > - 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. Yep, it's already done this way without problems and without the need for build-conflicts. > - Problem: Package foo needs debassistant >= 0.8 to build, but > will not work with debassistant version 0.93 which has a horrible bug. Yep :-) > Solution: foo declares > Build-Depends: debassistant (>= 0.8), > debassistant (<< 0.93) | > debassistant (>> 0.93) Ok (though a bit complicated, but doesn't matter, it should be rarely necessary.) > 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. Hmm... Let's see where such conflicts are used currently: a2ps => !lprng, lpr, gs, psutils, bzip2, gv, ghostview, gettext, flex Hmm... don't remember exactly anymore, but I guess lpr is needed and doesn't like lprng in parallel. abuse => !svgalib-dummyg1 gnuplot => !svgalib-dummyg1, gnuplot Some packages would configure for svgalib if svgalib-dummy is installed. bash => !termcap-compat If termcap-compat is installed, configure will detect libtermcap before libncurses and link with the former. emacs20 => !emacs20 AFAICR emacs used the installed lisp files instead of the ones in the build dir, but this has been fixed some time ago. liece => emacs20, !libsocks-dev Can't remember... :-( plplot => g77, !f2c, itcl3.0-dev, python-numeric f2c doesn't conflict with g77, but is preferred by the config. rpm => !bzip2, m4, gettext, autoconf, automake, tetex-bin If bzip2 is installed, librpm.so will be linked with libbz2.so, which is unwanted. ruby => bison, !ruby And installed ruby can provoke version conflicts of the installed lib and the built lib. I think at least the cases of bash, plplot, and rpm are no bugs. Roman
