FS#20600 - [nmap] missing libnl dependency

Attached to Project: Arch Linux
Opened by Jared Henley (multixrulz) - Wednesday, 25 August 2010, 08:46 GMT
Last edited by Gaetan Bisson (vesath) - Thursday, 26 August 2010, 07:13 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture i686
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

nmap depends on libnl but it's not listed as a dependency in the nmap package

nmap version 5.21-2

$ nmap
nmap: error while loading shared libraries: libnl.so.1: cannot open shared object file: No such file or directory
# pacman -S --asdeps libnl
<<< libnl installs >>>
$ nmap
Nmap 5.21 ( http://nmap.org )
Usage: nmap [Scan Type(s)] [Options] {target specification}
<<< etc etc >>>
This task depends upon

Closed by  Gaetan Bisson (vesath)
Thursday, 26 August 2010, 07:13 GMT
Reason for closing:  Fixed
Comment by Jared Henley (multixrulz) - Wednesday, 25 August 2010, 09:04 GMT
Actually it's probably not "critical" but I'm still fairly new to bug reporting and I'll pay attention when it's changed.
Comment by Gaetan Bisson (vesath) - Wednesday, 25 August 2010, 09:52 GMT
Normally, nmap depends on libpcap which in turn depends on libnl.
Could you try updating libpcap and confirm that it solves this issue?
Comment by Leonid Isaev (lisaev) - Wednesday, 25 August 2010, 17:44 GMT
And if it doesn't, then it is not a bug report against nmap, but against libpcap...
Comment by Jared Henley (multixrulz) - Wednesday, 25 August 2010, 21:50 GMT
Removing libnl and re-installing libpcap installs libnl as it should.

I notice that libnl became a dependency for libpcap in April. It seems that occasionally when a dependency is added to a package, pacman doesn't install the new dependency during a system upgrade, but I've never had enough evidence to try filing a bug report as I usually find out quite some time later. What should I do to get this looked at?
Comment by Leonid Isaev (lisaev) - Thursday, 26 August 2010, 00:40 GMT
Yes, it seems to be a bug in libpcap's PKGBUILD. Here are the SVN revisions of both:
* nmap (Rev 66790 2010-02-01 08:55:16)
pkgver=5.21
depends=('pcre' 'openssl' 'libpcap>=1.0.0' 'lua')
* libpcap(Rev 70665 2010-02-28 06:24:10)
pkgver=1.0.0
depends=('glibc')

Please notice the dates. The latter should have included libnl as a dep.

I believe this issue is resolved in the current libpcap PKGBUILD.
Comment by Gaetan Bisson (vesath) - Thursday, 26 August 2010, 07:01 GMT
The current PKGBUILD is indeed correct; it's a bit weird because it was released more than four months ago... (Did you often upgrade with "-Syu" during that time?)
I'll close this bug but please open a new one if you have evidence showing pacman is at fault.

Loading...