Re: pkg/49661 (comms/asterisk patch to add pgsql and snmp options)

[Mike Bowie <mbowie%rocketspace.com@localhost>]

The following reply was made to PR pkg/49661; it has been noted by GNATS.

From: Mike Bowie <mbowie%rocketspace.com@localhost>
To: gnats-bugs%NetBSD.org@localhost, jnemeth%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, 
 pkgsrc-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/49661 (comms/asterisk patch to add pgsql and snmp options)
Date: Fri, 20 Mar 2015 15:27:16 -0700

 On 3/19/15 11:15 PM, John Nemeth wrote:
 > The following reply was made to PR pkg/49661; it has been noted by GNATS.
 >
 >        I'm certainly willing to consider your request.  However, I'm
 >   wondering why you don't just use ODBC?  I'm using that to access
 >   MySQL (in a variety of ways), and I find it works quite well.  It
 >   would also be more flexible.  I am trying to avoid a proliferation
 >   of options.  But, if it is something you really need, I certainly
 >   am willing to do stuff to encourage greater use of Asterisk on
 >   NetBSD.
 >
 >        BTW, is it working well for you?  I've been using comms/asterisk18
 >   in production, but that is getting long in the tooth, and it is
 >   time to move forward.
 >
 >
 
 Hi John,
 
 Thank you for the response, and thank you for your efforts on the package.
 
 Interesting that you see it as keeping options slim, while on our side 
 we treat it as a reduced dependency tree, and less points of 
 configuration. I'm interested to know what drives that angle, since I've 
 previously made a point of supporting many ./configure tunables via 
 options when I write our packages internally. I tend to see it as if the 
 overarching project supports it, it's not for the handy-wrapper to pick 
 and choose what the end user should or  should not do; short of platform 
 specific limitations or incompatibilities. (Or perhaps glaring 
 bad-practices.)
 
 I'm not suggesting one option being superior to the other, and certainly 
 default to your judgement as the maintainer.
 
 As luck should have it, it sounds like we're in much the same boat as 
 you seem to be. We have a pair of 1.8 systems which have been in 
 production for going on four years now, which we're carefully preparing 
 to transition over to the current version. We'll definitely be keeping 
 the 1.8 systems near-line for a while after the transition.
 
 Best,
 
 Mike.