On Tue, 03 Jul 2018, Ferenc Wágner wrote: > When building packages in clean chroots many configure checks are > expected to fail not finding their dependencies. This is fine. Until > somebody tries to build the package in a not so clean chroot, where the > additional packages present satisfy some of these checks enabling extra > features. Or even breaking the build by exposing bugs (see #874600 for > an example). > > Is adding all possible --disable-whatever options to the configure call > a good practice? It clutters debian/rules, isn't easy to do > exhaustively in an obviously correct way, but protects against some > changes in the build environment. I'm interested in hearing your takes > on the issue.
You could disable them in configure, yes. But often this is addressed as build-conflicts, instead. Especially when you're not going to *really* test if the end result with the undesired dependencies installed but the feature disabled in configure. Which one is best depends really on how easy you want to make for people to selectively enable these features on local rebuilds. -- Henrique Holschuh
