[Nagiosplug-devel] post-1.3.0 features

[Jeremy T. Bouse]

On Thu, Mar 06, 2003 at 06:43:08AM -0500, Karl DeBisschop wrote:
> On Thu, 2003-03-06 at 03:26, Voon, Ton wrote:
> > Couple of things I'd like to work on:
> > - move snprintf into lib
> 
> Since we have lib now, this clearly makes sense. Should utils and
> netutils also move?
>
	I have to echo Tom on this one and say I think utils and netutils should
remain where they are... What I had planned on putting in lib/ was the
getaddrinfo emulation code as it is only needed if the system does not have the
RFC 2553/POSIX compliant functions. I'm looking at reusing the GPL'd code from
libesmtp that does this for you automatically... I feel utils and netutils are
still cornerstone objects for the plugins not external so they should not reside
in lib/ but right where they are in plugins/...
 
> > - update autoconf and automake to later versions
> 
> I don't want to do this quite yet - I think the penetration of RedHat
> 7.3 is still too deep. And since right now, newer automake works with
> the cost of a few warnings, I think we should wait still.
> 
	I would say if it ain't broke, don't fix it... Just yet anyway... I know
until I downgraded autoconf and automake I was having problems even getting
configure to execute here locally during the beta stage...

> > - strip'ing of executables at install time
> 
> Makes sense, I guess. RPM does it for me, so I havn't thought about
> putting it into the Makefile. But I guess not every uses RPM. Good idea.
> 
	Actually from my knowledge of Debian packaging it usually strips
binaries as well before making the package itself... I don't see any reason why
it shouldn't be done by default, although I might suggest we think about a way
to enable debugging where it doesn't strip for when we try to track down a bug
in the code sometime in the future if we do move to stripping by default...

> > - remove have_getopt_long references
> 
> Yup. It's dead wood, it should go away.
> 
> > And of course all the bug fixing...
> 
> we have bugs?  ;-)
> 
> > If there's going to be a branch in the code, should the sfsnapshot have
> > both?
> 
> There already is a branch.
> 
> Yes we probably should snapshot both.
> 
> --
> Karl
>