header sanity check?

[Tyler MacDonald <tyler@yi.org>]

I just created a /usr/local/include/hi_there.h , #include'd it from a header
file, and built a -dev debian package containing that header file without
any sort of warnings or errors.

So it's really easy to package a -dev package with a header file, that
#include's a header file in a package that it doesn't depend on.

Going through Developer's Corner I don't see anything that helps define how
to catch this or if there are any requirements. pbuilder won't even catch it
if the Build-Depends for the source package contains all the -dev packages
needed.

Is there anything like dh_headerdeps or guidelines on how -dev packages
should depend on eachother?

My gut feeling is that:

	1. If you #include a header directly, you have to depend on that
package.

	2. If you #include a header of a package that #includes a header
whose definitions you use (eg; #including httpd.h and then using apr_
stuff), and stick to stuff that is part of the former header's published
interface (eg; using apr_status_t), you're okay if you just depend on the
former -dev package.

	3. If you do the above but use part of the latter's header that
*isn't* part of the former's public interface (eg; APR_HAS_UNICODE_FS), then
you're not only dealing with (or being) a lazy C programmer, you also have
to depend on the latter -dev package as well.

	4. If you #include a header that doesn't belong to *any* package
(including the source package you're currently building), that's just
outright evil.

I also think that #1 and #4 would be easy (trivial, even) to catch in some
automated way, and that would make an excellent addition to lintian and/or
linda... #2 and #3 might be more tricky. At least determining #1, and
providing a ${headers:Depends} value would be a valuable tool to
maintainers and should be possible in most cases.

Is it worth doing? Has it been done or hashed out already?

	Thanks,
		Tyler