[csw-maintainers] Strange behaviour when depend file gets created

Roger Håkansson hson at opencsw.org
Mon Mar 9 03:05:40 CET 2009


I don't know what has happened, but somehow I've seem to have broken 
something on my build-machines lately.

When trying to package libnids, the depend file seem to get created wrongly.

The last part of "gmake package" looks like this:

Examining 'depend' file
application CSWggettextrt        ggettextrt - GNU locale utilities
application CSWglib2       glib2 - The low-level core lib for GNOME and GTK+
system      CSWlibnet      libnet - the libnet packet construction library
application CSWlibpcap     libpcap - Libpcap is a system-independent 
interface for user-level packet capture
P CSWcommon common - common files and dirs for CSW packages

system      CSWcommon      common - common files and dirs for CSW packages
Building index from SVR4 installed packages database...
(May take a while)
Cross-referencing indexes...
   found CSWglib2 for libglib-2.0.so.0
   found CSWglib2 for libgthread-2.0.so.0
   found CSWggettextrt for libintl.so.8
   found CSWlibnet for libnet.so
   found SUNWcsl for libnsl.so.1
   found CSWlibpcap for libpcap.so
   found SUNWcsl for libpthread.so.1
   found SUNWcsl for librt.so.1
   found SUNWcsl for libsocket.so.1
   found SUNWcsl for libthread.so.1
SUGGESTION: you may want to add some or all of the following as depends:
    (Feel free to ignore SUNW or SPRO packages)
 > CSWggettextrt
 > CSWglib2
 > CSWlibnet
 > CSWlibpcap
 > SUNWcsl

Examining the CSWlibnids.depend, it actually looks like this:

application CSWggettextrt        ggettextrt - GNU locale utilities
application CSWglib2       glib2 - The low-level core lib for GNOME and GTK+
system      CSWlibnet      libnet - the libnet packet construction library
application CSWlibpcap     libpcap - Libpcap is a system-independent 
interface f
or user-level packet capture
P CSWcommon common - common files and dirs for CSW packages


When building on the buildfarm, the output from checkpkg looks like this:
Examining 'depend' file
P CSWggettextrt ggettextrt - GNU locale utilities
P CSWglib2 glib2 - The low-level core lib for GNOME and GTK+
P CSWlibnet libnet - the libnet packet construction library
P CSWlibpcap libpcap - Libpcap is a system-independent interface for 
user-level packet capture
P CSWcommon common - common files and dirs for CSW packages

system      CSWcommon      common - common files and dirs for CSW packages
application CSWggettextrt        ggettextrt - GNU locale utilities
application CSWglib2       glib2 - The low-level core lib for GNOME and GTK+
system      CSWlibnet      libnet - the libnet packet construction library
application CSWlibpcap     libpcap - Libpcap is a system-independent 
interface for user-level packet capture
Building index from SVR4 installed packages database...
(May take a while)
Cross-referencing indexes...
   found CSWglib2 for libglib-2.0.so.0
   found CSWglib2 for libgthread-2.0.so.0
   found CSWggettextrt for libintl.so.8
   found CSWjre6 for libnet.so
   found SUNWcslx for libnsl.so.1
   found CSWlibpcap for libpcap.so
   found SUNWcslx for libpthread.so.1
   found SUNWcslx for librt.so.1
   found SUNWcslx for libsocket.so.1
   found SUNWcslx for libthread.so.1
SUGGESTION: you may want to add some or all of the following as depends:
    (Feel free to ignore SUNW or SPRO packages)
 > CSWjre6
 > SUNWcslx

And the CSWlibnids.depend looks just like expected:
P CSWggettextrt ggettextrt - GNU locale utilities
P CSWglib2 glib2 - The low-level core lib for GNOME and GTK+
P CSWlibnet libnet - the libnet packet construction library
P CSWlibpcap libpcap - Libpcap is a system-independent interface for 
user-level
packet capture
P CSWcommon common - common files and dirs for CSW packages



I've tried reverting to an older cswutils-package, but with the same 
behaviour.
I've installed a lot of packages lately in order to build a bunch of 
packages so some of them might be the cause of the problem, but before I 
start to remove them, I'm just wondering if anyone have a clue what 
might be the problem?



More information about the maintainers mailing list