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

[Thomas Guyot-Sionnest]

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

Andreas Ericsson wrote:
| For some reason your MUA double-wrapped everything.
| Could you look into your settings, Ton?
|
| ton.voon at altinity.com wrote:
|> The 3rd party code in question here is only for testing purposes. It is
|> only enabled with a configure flag, so, outside of development, will not
|> usually be used.
|>
|
| Then why is it needed? If it's just for tinderbox builds, why not install
| it on the various tinderboxen? If it's not for tinderbox builds, why ship
| it at all? If someone needs to test libtap functionality they can jolly
| well install libtap imo.

The problem is that libtab is pretty much unmaintained, and can be
pretty hard to install on some architectures. This is specially on
special architecture that testing comes in handy.

Also we could encourage users to report failed tests. Most users won't
install tap on their system just for the purpose of testing.

|> A more entrenched example would be GNU lib - we embed their code (at
their
|> recommendation).
|
| While we're at it, I'm pretty much against this too. Plugins, weighing
| in at an average of 555.57 LoC, that can't be made to run without a
| rather large compatibility library need to be looked over. Especially
| when the functions gnulib typically provides are along the lines of
| strndup(), vasnprintf(), full_write() et al. As it is, the compat lib
| is more than twice the size of the code it's providing compatibility
| for.

The goal is to provide cross-platform compatibility. Rather than waiting
on user to report problems we included a common set of libraries.
There's also some GL modules what provide us with useful functions, like
getting disk usage in a cross-platform fashion.

The build system include only required Gnulib code, so although it's
more code than the plugins themselves it's not something that should
increase the size of your compiled plugins.

|> Theoretically, a security exposure could be found there.
|> But we have a very simple process to update their software and cut a new
|> package. There's no way I would want this project, or any others that use
|> gnulib, to have to recode all the functionality they provide.
|>
|
| It'll be even easier when you move to git, as you can then use gnulib
| as ae submodule (Jim Meyering who maintains gnulib is an avid git-fan
| and contributor) ;-)

I'm not too sure about this way of doing it, because normally you use
Gnulib's scripts to update the modules. It's simple and fast.

It would also mean we'd end up with the whole Gnulib repository rather
than the subset of modules we included.

|> I can't guarantee that we will not include 3rd party software in
future. We
|> have to make a judgement on whether a 3rd party piece of code will
provide
|> us features or cross platform capabilities we need without
re-inventing the
|> wheel. That's a compromise we have to make. However, when possible,
we will
|> allow configure options to disable 3rd party code.
|>
|
| Sometimes, reinventing the wheel (or importing a handful of 10-line
| functions) is preferrable to including the whole shebang.

And how will you guarantee compatibility across all platform
Nagios-plugins get compiled on? I don't want to disappoint you but I
don't see any compelling reason to change the way we do regarding Gnulib
(I do have enhancements regarding libtap that have been discussed in the
#nagios-devel channel this morning though).

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

iD8DBQFIrxHV6dZ+Kt5BchYRAg0AAKCNUEpDS7a2cl0qdn55uFzMy/RbgQCbB9tC
BXkx7zHddYl94D2rdtTiQN4=
=Qfyf
-----END PGP SIGNATURE-----