Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> 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
Reply to: