[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]

On Tue, 10 Feb 2009 13:25:53 +0100
Fabian Greffrath <greffrath@leat.rub.de> wrote:

> Steve Langasek schrieb:
> > This is a very bad idea.  It interferes with reproducibility of binary
> > builds, which is a very important property of Debian packages.  Packages
> > must *not* build differently based on opportunistic discovery of
> > build-dependencies on the system - it's a bug for any package to do so, let
> > alone to be specifically encouraging this behavior with debian/control
> > fields!
> Alright, this speaks clearly against Build-Recommends. However, would 
> you consider at least Build-Suggests useful enough to support them?

AIUI, your original suggestion was that Build-Suggests was for use with
external repositories, so it doesn't make any sense to have this data in
debian/control where Policy requires that packages can only
Build-Depend on packages that exist in Debian (i.e. must build from
source in a sane way).

If a package has extra functionality then Steve's point about *not
discovering* such support is still valid - the program must default to
OFF unless specifically configured to ON for the relevant switch.
Builds must ignore any incidental packages that exist unless
specifically requested to use them - which means changing debian/rules
from --disable-foo to --enable-foo or similar.

So IMHO the right place for information on what the package *can* do if
suitably configured, is README.Debian - not debian/control - because
merely installing the suggested package from whatever source must NOT
allow the package to use this support within the build, the build
itself (i.e. debian/rules) must be modified to look for this support.


Neil Williams

Attachment: pgpezCwmoMjDq.pgp
Description: PGP signature

Reply to: