On Sun, May 12, 2002 at 01:52:47PM +0200, Torsten Landschoff wrote:
> I am working on the Debian package for 0.7.1 and I am wondering about
>
> http://bugs.debian.org/132359
>
> In short the versioning of the package is questionable. The Debian package
> should be named libpcap<major> where <major> is the major and interface
> version of the library. Therefore I used "0" as major number but I am
> not sure if 0.7.1 breaks the interface of older versions.
As far as I know, we haven't made any releases that break the binary
interface of older releases (other than perhaps a problem with libpcap
0.5[.x] changing the values of some DLT_ types that had different values
on different BSD systems, e.g. DLT_RAW; 0.6[.x] reverted to the previous
versions, though).
> I am wondering if I should be using 0.7 for the new release instead to
> fix this silly dependency. Upstream libpcap is not built as a shared
> library so I am a bit on my own here. I wonder if I should submit a
> patch to always build a shared library.
Such a patch would, of course, either
1) have to build a shared library only on platforms using the
GNU linker
or
2) use libtool
as the mechanism for building a shared library differs significantly
between UNIX systems.
That might also affect the tcpdump build; if somebody downloads both
libpcap and tcpdump, and unpacks them in subdirectories of the same
directory, configures and builds libpcap, and configures and builds
tcpdump, if building libpcap as a shared library causes tcpdump to link
with that shared library, the resulting tcpdump binary might not work
when run from directories other than the one in which it's built, if
doing so means it can't find the libpcap shared library.
I don't know whether that's a major issue, though.
> Would you accept such a change?
If it didn't break the build on non-GNU-linker platforms, and didn't
cause problems with downloading and building libpcap and tcpdump in the
same directory (so that tcpdump picks up the shared library from
../libpcap-X.Y and link with the file in that directory at run time), I
don't see a problem with it offhand.
> In any case I need to know what the official interface version of the
> library is supposed to be.
At least with SVR4-style shared libraries (the shared libraries in the
free UNIXes are either SunOS 4.x-style, if ELF isn't being used, or
SVR4-style, if ELF is being used), I'd say that, using the terminology
of
http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
the soname should be "libpcap.so.0" and, on systems that have the notion
of a "real name" (Linux distributions are the only systems I know of
that use SVR4-style shared libraries and give them "real names"), the
"real name" would be "libpcap.so.0.7.1" for the current version.
For SunOS 4.x-style shared libraries, the library name for the current
version would be "libpcap.so.0.7".
Unfortunately, I'm not familiar with the Debian rules for package
version numbers (is that somewhere on the Debian site?), so I can't
suggest what the "right" version number is for the libpcap package.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
