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

[Richard Braakman <dark@xs4all.nl>]

Roman Hodek wrote:
> But it's something different here... It's really trivial to
> temporatily uninstall a package and reinstall it later.

What if you can only uninstall the package by deconfiguring another one
that you need?  Take this situation:

foo-source has
  Build-Depends: gnu1 | gnu2
  Build-Conflicts: bar

gnu1 has
  Depends: bar

Currently bar and gnu1 are installed.  Will your five lines of code be
able to uninstall bar, uninstall gnu1, and install gnu2?

> 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.

Hmm, lprng Provides lpr (and Conflicts with it).  I guess this
expresses that lprng won't do.

> abuse => !svgalib-dummyg1
> gnuplot => !svgalib-dummyg1, gnuplot
> 
>   Some packages would configure for svgalib if svgalib-dummy is installed.

They should be configured not to use svgalib, via options in debian/rules.
This should not depend on the build environment.  (If it does, it's
far too easy to silently build without it, even on a platform that
does need it).

> bash => !termcap-compat
> 
>   If termcap-compat is installed, configure will detect libtermcap
>   before libncurses and link with the former.

Also a packaging bug.  Bash should be told to use libncurses, regardless
of the build environment.

> 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.

(and so forth)... these should all be told to configure the right way,
regardless of build environment.  Build-time configuration is nice, but
not if you want the binary package to be easily reproducible.  I've
already seen far too many bugs in NMUs caused by packages silently built
with the wrong configuration.  Also, the normal course for a user who
is faced with a core dump is to try to get a backtrace by compiling the
program with debugging symbols.

> ruby => bison, !ruby
> 
>   And installed ruby can provoke version conflicts of the installed
>   lib and the built lib.

Definitely a bug in ruby's build environment... imagine these :-)

gcc => binutils, !gcc
perl => !perl

> I think at least the cases of bash, plplot, and rpm are no bugs.

I think they are, for the reasons I've given above.

Richard Braakman