[Pkg-nagios-devel] [Nagiosplug-devel] Libtap included in distribution

[Ton Voon]

Hi Sean,

On 22 Aug 2008, at 17:12, sean finney wrote:

> 	"embedding code is okay, as long as you do not force users/packages/ 
> etc to
> 	 use your embedded version"

That's a good principle. I'll update our dev guidelines (as soon as I  
get docbook working on my mac again).

> for example, PHP typically bundles the gd image library, imap client  
> library,
> etc with their code.  both of these libraries have a long and ugly  
> history
> security-wise, which in turn resulted in the upstream PHP project  
> needed to
> release security updates due to their bundled code.   also, they  
> bundle stuff
> like timezone data, which is a major pain in the ass to keep up to  
> date (we
> recently patched that feature out, but i digress)

Nagios Plugins as a project is very difficult because we need 3rd  
party frameworks for relatively little functionality (whereas I can  
see GD would be a big gain for PHP). For instance, we need mysql  
libraries for check_mysql to work. I guess we could include  
msqlclient, but we've made a decision that the benefit of including  
this 3rd party code is very little compared to the risk of changes to  
the interface.

I'm just flagging that this decision may be different for other code  
in future, but we definitely consider it carefully.

> debian and others choose to build such packages using the distro- 
> provided
> libraries instead, thus making bundled code unneeded but ultimately  
> harmless.
> in most/ideal cases it's just a matter of passing --with-foo=/usr or  
> similar
> to a configure script which will override the default behaviour of  
> using the
> bundled version.
>
> if nagios-plugins could/does provide similar functionality, i think  
> the
> problem is essentially moot.

I think this will always be the case. You can hold it to me if not :)

> however, note that "do not force them to use your version" also  
> means you
> shouldn't make any incompatible changes to the bundled code, as it  
> would
> prevent others from using their local system versions.  i saw some  
> mention
> earlier of needing to make a change in libtap for example.... though  
> maybe
> that's not as grave since upstream work for that seems dead (you  
> should email
> your patch anyway, as well as have it documented for posterity  
> though, i'd
> say).

The only patches we made are for http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/25 
  and http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/32, not interface  
changes.

As you say, the upstream project appears dead. But I don't fancy  
reimplementing the functionality...

And how come your email is refers to the project as "you" - you still  
have commit access, right? :)

Ton

http://www.altinity.com
UK: +44 (0)870 787 9243
US: +1 866 879 9184
Fax: +44 (0)845 280 1725
Skype: tonvoon