In some email I received from Frank van der Linden, sie wrote:
> 
> On Mon, Dec 07, 1998 at 01:09:06AM +0100, Hubert Feyrer wrote:
> > 
> > In general, everything that needs some definitions made in another file
> > would be optimal. I've stumbled across netinet/ip.h wanting type n_time,
> > which I found to be defined in netinet/in_systm.h today, and it's probably
> > some others.  (And I guess I better don't ask that source level
> > compatibility w/ some penguin driven OS would be nice in that area - but
> > then what do I know about anything of either's network programming :-/)
> 
> Well.. if our header files require including some other, obscure
> include files, while this is not needed on several (not just one)
> systems, then they should probably be fixed. But it is normal practice
> that an include file requires the inclusion of another, it would be wrong
> to bloat all include files just because you can't compile Linux source
> out of the box. Unfortunately, there seems to be quite a bit of software
> written on Linux that isn't very portable.

You could of course take the approach used by other people writing free
unixes and move structures from one header file to another because you
feel it should be somewhere else and become incompatible with everyone
else.  In a single change, FreeBSD went from compiling tcpdump with no
chanegs to requiring fleas specific changes.

FWIW, I don't believe that anyone should think about being compatible with
Linux include files.  Right now their kernel includes are about as
incompatible as you could get with the new defacto standard for /usr/include
(glibc).  If they truely want to be compatible (look for _BSD_SOURCES in the
.h files), then they should compile cleanly with netinet/in_systm.h being
included, followed by netinet/ip.h.

The problem is for them to become compatible with us (and everyone else),
not the other way.