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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpezCwmoMjDq.pgp
Description: PGP signature