[Nagiosplug-devel] Libtap included in distribution

[Jan Wagner]

Hi there again,

I feel a bit worried about some reactions on my mail. It was not my intention 
to start any flamewars. Maybe I did not choose the words with the correct 
nuance. :/

On Friday 22 August 2008 18:12, sean finney wrote:
> on the issue of embedding 3rd-party code, i think the situation is a little
> more nuanced then "include it or do not include it".  my personal
> recommendation, from having worked in this and other projects that wish to
> do so, as well as with the debian security team who often have to deal with
> the problem, is roughly as follows:
>
> 	"embedding code is okay, as long as you do not force users/packages/etc to
> 	 use your embedded version"
>
> providing bundled code is a great way to ensure cross platform /
> environment consistency.   however, as jan mentioned, this has security
> implications if the bundled code ever has a serious security problem, or
> otherwise requires an update.

[...]

> 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.
>
> 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).

Sean, thanks for your wonderfull explanation. It's expressing exactly my 
opinion about the situation. 
As far there is no strong depency on the embedded code copies, I think it's 
just fine. Just after writing my mail I did give latest svn snapshot a try 
with removed libtap from source tree and I recognized, it compiles fine. So 
in this case I have the option to avoid using the embedded libtap.
Idealy there would be an option to use a external libtap via an option as sean 
described, but as far as I understand you modified your shipped libtap, so 
this wouldn't be an equivalent replacement for your version of libtap.

> also, as an aside, i don't think libtap is packaged in debian at the moment

No it isn't, but as long as it's possible to avoid using the shipped libtap, 
that would be fine.

> (i tried packaging it a year or two back and ran into some problem before
> losing interest), though i do see gnulib packages.

For gnulib the situation is a way different. You depending heavily on (your 
shipped) gnulib and there is no way neither to avoid using the shipped gnulib 
code nor using a external gnulib copy. Is there a possibility that you 
provide --path-gnulib= or something like that in the future? For example 
Debian has a package gnulib which can be used for this (if you don't changed 
anything in your embedded copy or don't rely on this modifications) I guess.

With kind regards, Jan.
-- 
Never write mail to <waja at spamfalle.info>, you have been warned!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE
Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++
------END GEEK CODE BLOCK------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20080822/c23f2989/attachment.sig>