lib/45730: two copies of bpf.h in /usr/include

[dholland%netbsd.org@localhost]

>Number:         45730
>Category:       lib
>Synopsis:       two copies of bpf.h in /usr/include
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 21 17:50:00 +0000 2011
>Originator:     David A. Holland
>Release:        current of 20111221
>Organization:
>Environment:
n/a
>Description:

There are now two copies of bpf.h in /usr/include, one (net/bpf.h)
native and one (pcap/bpf.h) belonging to libpcap.

This causes confusion, and several packages end up including both and
failing to build.

If libpcap has its own and entirely separate bpf implementation (that
is, it pulls all packets from the kernel and bpf's them itself in
userspace) then having its own version seems reasonable; however, this
seems like a stupid design. If on the other hand it's going to be
loading bpf code into the kernel, it should share the declarations, as
much as hacking it up to do so will be a pain.

Or so I'd think. If not, there needs to be some clear way for
3rd-party code to figure out what to do.

>How-To-Repeat:

>Fix: