> $ dpkg-buildpackage -b -nc -uc -us > dpkg-buildpackage: […] > dpkg-checkbuilddeps: error: Unmet build dependencies: foobarbaz > dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting > dpkg-buildpackage: warning: (Use -d flag to override.)
> Please remove the "override" line. This is almost never what you actually > want to do. This message confuses novice users who want to recompile > something into thinking that this will do anything to solve their problem. > It won't, they now have three problems instead. I disagree, this reminder is very useful and saves us having to dig in the man page (non-novices too often don't remember all options from the top of our heads). It's vital for "dpkg-buildpackage -S" -- many of us use sbuild for binary builds so build-dependencies are unlikely to be installed on the host. It's especially annoying if you do porting or qa as you handle many many packages. A source build can fail with -d (dh-ocaml, gnome-pkg-tools, etc) but such failures tend to be obvious and you still don't need to install the rest. Matthias' reasoning is more valid for "dpkg-buildpackage -b", but his claim "almost never" is thoroughly untrue. An end-user has no reason to rebuild packages without doing _something_ out of the ordinary: be it a backport to stable, applying a patch, specifying a build option, etc. In such cases it's likely the build-dependencies may be not satisfied for a legitimate reason. Sure, the build may then fail, but no -d is the default so the user has to specify -d consciously. Thus, I propose leaving the message as is. Meow! -- A tit a day keeps the vet away.
