On Sat, Jul 09, 2005 at 05:20:15PM +0200, Romain Francoise wrote: > 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. > 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. Apparently, there is only *one* package in testing (tcpdump) that currently depends on libpcap0.9. If libpcap0.9 is actually backwards-compatible with libpcap0.8, wouldn't it be far better to restore the libpcap0.8 package name so that only one package has to be rebuilt for the 0.9->0.8 transition, instead of rebuilding 20-some packages for an 0.8->0.9 transition? I don't see any reason why this wouldn't work, and it would certainly be a lot easier. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature