[Nagiosplug-devel] Libtap included in distribution
waja at cyconet.org
Fri Aug 22 21:02:16 CEST 2008
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
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-----
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
Size: 189 bytes
Desc: not available
More information about the Devel