[arch-dev-public] [arch-commits] CVS update of core/base/libpcap (PKGBUILD)

[Aaron Griffin]

On 10/7/07, Jan de Groot <jan at jgc.homeip.net> wrote:
> On Sun, 2007-10-07 at 07:42 -0400, Thomas Baechler wrote:
> > Date: Sunday, October 7, 2007 @ 07:42:13
> >   Author: thomas
> >     Path: /home/cvs-core/core/base/libpcap
> >
> > +# This package has a strict SONAME that changes in EVERY MINOR
> > +# release. Whenever you feel like updating this package, DON'T,
> > +# it will break a number of essential system tools.
> > +# Again, for dummies: IF YOU UPDATE THIS PACKAGE DIRECTLY TO CORE,
> > +# I WILL PERSONALLY CHOP YOUR HEAD OFF!
>
> Morning Mr Head Chopper...
>
> I looked at this package yesterday, it seems something is plain wrong
> with the soname versioning. I took a look at the debian package, where
> we retrieved the shared library patch from 2 years ago (yes, libpcap was
> one of the first packages I changed when I had current access). It seems
> they keep track whether a release is API/ABI stable and keep the soname
> the same. FYI: They have libpcap.so.0.9.8 and libpcap.so.0.8, as the
> 0.9.x versions share the same ABI as the 0.8 versions. They update their
> patches to keep things working.
> I'm thinking about two solutions here:
> - Make sure apps stop linking against the .so.0.9.x library, apps should
> link to the normal soname that doesn't change on minor version bumps
> - remove the patch completely and continue to use the static library as
> the libpcap project does upstream
>
> Solution 1 looks hard, but all it takes is updating the shared lib patch
> and adjust it to not look at the debian changelog to generate its
> sonames.

I don't know much of the details here, but at a glance I'd side with
#2. The reason being two fold:

1) It is the path of least resistance. That is, it's a far easier change.
2) It's what the upstream devs intend.

It requires a rebuild for all child packages, but it does currently,
and won't break things in the process.