Re: [arch-dev-public] [arch-commits] CVS update of core/base/libpcap (PKGBUILD)
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.
On 10/7/07, Jan de Groot <jan@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.
participants (2)
-
Aaron Griffin
-
Jan de Groot