Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-0.2.9smp i686; en-US; 0.7) Gecko/20010316 Description of problem: It would be nice if the libpcap rpm contained the shared library libpcap.so.0 so other programs (e.g. tcptraceroute) would work "out-of-the-box". How reproducible: Always Steps to Reproduce: 1.rpm -qpl libpcap-0.4-39.i386.rpm Actual Results: /usr/include/pcap /usr/include/pcap/net /usr/include/pcap/net/bpf.h /usr/include/pcap/pcap-namedb.h /usr/include/pcap/pcap.h /usr/lib/libpcap.a /usr/share/doc/libpcap-0.4 /usr/share/doc/libpcap-0.4/CHANGES /usr/share/doc/libpcap-0.4/README /usr/share/man/man3/pcap.3.gz Expected Results: There should be a /usr/lib/libpcap.so.0 or something similar. Additional info:
Indeed. I missed this shared lib ten minutes ago, too...
There is no libpcap.so target in the Makefile of the official libpcap tarball.
I took the liberty of reopening this bug as an enhancement. While it may be true that "there is no libpcap.so target in the Makefile of the official libpcap tarball", Linux Mandrake includes one in their libpcap packages. As a matter of fact, I am using their libpcap-0.5-2mdk RPM right now. If you would like I can take a look at their source RPM and let you know how they got a shared library out of it. I really like RedHat Linux much more than Mandrake, and I would hate to see such a simple thing as this be a check for Mandrake and not for RedHat. Especially since it is all Open Source/Free Software anyway, right? I mean, we are supposed to be cross pollinating and sharing ideas and enhancements right?
no problem. I can quickhack produce some shared library, too. ;) The problem is: there is no official major.minor number for that library. OK, I can take the tarball version, but that does not assure the correct major/minor philosophie of library interfaces.
> there is no official major.minor number for that library hmm... a subtlety I had overlooked. It seems that Mandrake just uses the tarball version, but I can see how that could potentially be problematic. Maybe this should be taken up with the libpcap people. For all we know they could be numbering their tarballs in just such a way as to avoid this issue. Or maybe they should start doing that... The real question is what to do now: hack it, or leave it. I say hack it. It won't be a problem until libpcap jumps to 1.x. Until then somebody can try to convince them to address this issue if they already haven't, and we RedHat users aren't left out in the cold.
libpcap-0.6.2-7.i386.rpm