ネイティブ呼び出しに使用する so ファイルは、libpcap0.9 に依存しています。
Debian にはlibpcap0.9がありません:
https://packages.debian.org/search?keywords=libpcap&searchon=names&suite=stable§ion=all
https://packages.debian.org/search?keywords=libpcap0.9&searchon=names&suite=stable§ion=all
ある時点で libpcap0.9 があったようですが、存在する理由がなかったので削除されました。そのレポートが言うように、「libpcap0.9 ソース パッケージはもう必要ありません。libpcap のバージョン 0.9 は libpcap0.8 と API および ABI 互換であることがわかりました」。
API または ABI が互換性のない方法で変更された場合にのみ、おそらく "libpcap0.8" 以外の名前に変更されます。また、公開された libpcap API または ABI が互換性を損なうような方法で変更されることを許可するつもりはありませpcap_tん。以前のバージョンの libpcap でビルドされたプログラム (構造のレイアウトは公開された API または ABI の一部ではないことに注意してください...)。したがって、私が libpcap のコア開発者である限り、libpcap のバージョン 1.N+1 は API およびバージョン 1.N と互換性のある ABI になります。 1.N+1 ですが、1.N+1 で構築されたプログラムは、これらの新しい機能を使用すると、1.N では動作しません (ソフトウェアの動作方法です)。
SVN リポジトリから jnetpcap ソースを見ると、releases/jnetpcap-1.3/release-1.3.0-1/src/deb/jnetpcap-1.controlファイルには次のように書かれています。
Depends: libpcap-dev (>= 0.8)
0.8 は、= (または、C コードを書いている場合は ==) 0.8 であることを考えると、確かに >= 0.8 です。
古い jnetpcap リリースには
Depends: libpcap0.8 (>= 0.9)
しかし、それでも「libpcap0.9」への依存関係を生成するべきではなく、バージョン番号 >= 0.9 の libpcap0.8 への依存関係を生成する必要があります。
また、wheezy にはバージョン番号 1.3.0-1 の libpcap0.8があり、1.3.0-1 は >= 0.9 であるため、wheezy は "libpcap0.8 (>= 0.9 )" 1) その Depends: の行が、私が期待する意味を意味していないか、2) 依存関係のチェックが壊れていて、libpcap 1.3.0 が libpcap 0.9 よりも確実に新しいことに気付いていない場合を除きます。