Preparing the libpcap transition

[Romain Francoise <rfrancoise@debian.org>]

For etch I want to reduce the number of concurrent versions of libpcap
and keep only libpcap0.9.  Right now we have three versions in unstable:

- libpcap, the old legacy version.  It was the default libpcap version
  for sarge.  It provides libpcap0.7, libpcap0.7-dev and libpcap-dev
  which is both a virtual and dummy binary package, and has 58 reverse
  dependencies.

- libpcap0.8, which was introduced late in the sarge release cycle to
  support new upstream versions of some of its reverse dependencies such
  as tcpdump and ethereal (at the time I felt it wasn't reasonable to
  force a migration of all packages, in hindsight we probably would have
  had the time).  It provides libpcap0.8 and libpcap0.8-dev, and has 31
  reverse dependencies.

- libpcap0.9 is the latest (major) upstream version, 0.9.1 was released
  this week and 0.9.2 is planned for tomorrow to fix minor problems in
  the new API.

My tentative plan is simply to move libpcap-dev to libpcap0.9 and ask
people to rebuild packages to migrate to libpcap0.9.  Porting should be
pretty straightforward in most cases and trivial if moving from
libpcap0.8 since the new library is API (and ABI) forwards-compatible[1]
with libpcap0.8.  Depending on how fast things go, asking for the
removal of the old versions in September sounds reasonable.

I'd like to get the ok of the release team before proceeding.

Thanks,

-- 
  ,''`.
 : :' :        Romain Francoise <rfrancoise@debian.org>
 `. `'         http://people.debian.org/~rfrancoise/
   `-

Footnotes:
[1] Which means that changing the soname and package name wasn't
    necessary.  When I first packaged libpcap0.9 for experimental, I
    didn't know there would be no incompatible changes to the API and
    took the safe route.