Subject: pkg/23797: net/libpcap buildlink2.mk problem on -stable
To: None <gnats-bugs@gnats.netbsd.org>
From: None <dotz@irc.pl>
List: netbsd-bugs
Date: 12/18/2003 23:17:07
>Number:         23797
>Category:       pkg
>Synopsis:       net/libpcap buildlink2.mk hardcodes libpcap version; trouble on -stable
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 18 23:18:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Michal Pasternak <dotz@irc.pl>
>Release:        NetBSD 1.6.1
>Organization:
Good People With Bad Reputation
>Environment:
	
>Description:

	Current net/libpcap/buildlink2.mk works on a very specific basis.

	Check this out:

.if exists(/usr/include/pcap.h)
_NEED_LIBPCAP=		NO
.else
_NEED_LIBPCAP=		YES
.endif

	This assumes, that I will always want the version in basesystem
	(/usr hierarchy), which is not always true, at least right _now_ -
	NetBSD-stable contains a bit older libpcap; some packages need
	newer version (see wip/py-pcapy I just ported a moment ago, with
	a very, very ugly hack inside the Makefile)

	
>How-To-Repeat:

	Compile anything, that needs libpcap 0.7.2 on NetBSD-stable system.

>Fix:

	Patches should be trival, patches are no issue here. The problem
	is to decide which solution to choose:

	1) let sysadmin decide (via setting USE_LIBPCAP=pkgsrc in /etc/mk.conf, 
	   for example) => will still cause trouble on -stable in case sysadmin
	   doesn't set it

	2) let the package decide which variant of libpcap it wants (via
	   overriding _NEED_LIBPCAP variable; variable should be of course
	   renamed in such case, as underscore marks "private" variables)

	3) let the package decide which *VERSION* of libpcap it wants; 
	   Currently on NetBSD-stable /usr/include/pcap.h defines:

#define PCAP_VERSION_MAJOR 2
#define PCAP_VERSION_MINOR 4
	   
	   So it is possible to filter out those values, compare them,
	   and install pkgsrc libpcap in case it is needed.

	There is also one more option possible:

	4) Don't bother with it; it's just one package; even if there were
	   more packages like this, we can wait for 2.0 (note I don't know
	   which libpcap is included in prepared 1.6.2 release)

	There are more situations like this, when you are using pkgsrc on
	non-NetBSD systems (eg. you have a full installation of RedHat Linux,
	you have many developer packages installed in /usr hierarchy, some
	of them will be recent enough to compile pkgsrc software; some of
	them will be not). It would be really good if we can at least work
	out a _method_ how to handle such situations. IMO the best would
	be 3rd method I proposed (and hardest to implement). Once again,
	commonly used devel packages (readline, ncurses, libpcap) could:

	1) check if there's a version in basesystem available:
		- via grep/sed or configure's conftest-like programs
		- via platform-specific software (get info from rpm or dpkg)

	2) if yes: if the needed version matches already installed basesystem
	   version, use the one from basesystem

	3) if no: proceed with normal installation

	Of course this would not work as expected in many cases (different Linux
	distros have different directory hierarchy), but it should be sufficient
	for simple devel packages, like the ones I mentioned.
>Release-Note:
>Audit-Trail:
>Unformatted: