pkg/37751: hidden dependence of spamassassin on p5-DB_File

[dholland%eecs.harvard.edu@localhost]

>Number:         37751
>Category:       pkg
>Synopsis:       hidden dependence of spamassassin on p5-DB_File
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 14 04:30:01 +0000 2008
>Originator:     David A. Holland <dholland%eecs.harvard.edu@localhost>
>Release:        NetBSD 2.1.0_STABLE (20071208)
>Organization:
>Environment:
System: NetBSD bantha 2.1.0_STABLE NetBSD 2.1.0_STABLE (BANTHA) #5: Sat Dec  8 
08:59:49 EST 2007  root@bantha:/usr/src/sys/arch/i386/compile/BANTHA i386
Architecture: i386
Machine: i386
>Description:

This morning while updating db4 I discovered the hard way that
spamassassin seems to depend on p5-DB_File, even though it doesn't say
so. Starting it after rebuilding db4 but not p5-DB_File (since the
latter didn't appear to be critical) resulted in this in syslog:

Jan 13 07:44:00 bantha spamd[1192]: Use of uninitialized value in
  numeric ge (>=) at 
  /usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd-thread-multi/DB_File.pm
  line 275.
Jan 13 07:44:00 bantha spamd[1192]: Use of uninitialized value in
  numeric gt (>) at
  /usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd-thread-multi/DB_File.pm
  line 279. 
Jan 13 07:44:00 bantha spamd[1192]: Deep recursion on subroutine 
  "DB_File::AUTOLOAD" at
  /usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd-thread-multi/DB_File.pm
   line 234. 

after which it apparently croaked. After rebuilding p5-DB_File
everything went fine.

pkg_info -R p5-DB_File comes up empty, and did so before I started
mucking with make replace, too.

>How-To-Repeat:

Rebuild db4 (with make replace) and not p5-DB_File, then try to start
spamd. Watch it croak inside a perl module it supposedly doesn't use.

You may need

   BDB_DEFAULT=db4
   BDB185_DEFAULT=db4

in mk.conf to get the same behavior.

>Fix:

It doesn't matter why it croaked, but the dependency does need to be
recorded. Unfortunately, I have no idea where it's coming from and I
don't know how to find out except by wading through tons of line
noise^H^H^H^H^H^H^H^H^H^H^H perl code. I'm hoping someone who knows
more about perl modules has a better way.