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

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Wagner wrote:
| 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.

Well, gnulib is not meant to be complied and installed as a library, but
rather used for compiling programs. Even if you have gnulib installed on
your system you would have to update the modules inside Nagios-plugins
tree (regarding that, is you were to update Gnulib in Nagios-plugins
before compilation on Debian, you should probably use Git HEAD instead
of another debian package).

There is no way we could directly link to an installed gnulib because it
is _not_ compiled! The only thing we could do is use that patch to run
gnulib-tool and import that gnulib to the plugin. However considering
that the plugins are tested against the specific gnulib version bundled
with it that would be a very bad idea. It would also likely running
autoheader, automake and autoconf again and many system arett properly
set-up for that step.

For every other library beside libtab (used for testing only) we just
don't build plugins that libraqries that are missing. Regarding
Nagios::Plugin Perl module, IIRC the idea is to eventually install it
_locally_ in the libexec dir for availability to our own Perl plugins,
unless user specify to use the system-wide module OR to install the
buldled module system-wide. Again, this is so that we can test and
install our plugins against a specific version of the module without
interfering with anything on the system.

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIrxbL6dZ+Kt5BchYRAvOQAJ9BNCKwYdyqZ3DHrHot4ANTvHDfcACcCu74
uNAN7xIN+UhY1DpsZ8wfS3s=
=uSg5
-----END PGP SIGNATURE-----