[Pkg-nagios-devel] Standard for naming Nagios-/Icinga-plugins

[Jan Wagner]

Heya!

On Friday 19 March 2010 17:41:11 Morten Werner Forsbring wrote:
> Alexander Wirt <formorer at formorer.de> writes:
> > We (as in Jan Wagner and me) would prefer a naming like
> > nagios-plugins-openmanage.
>
> That implies that there is more than one plugin in the package. For
> one-plugin-packages I would personally prefer
> nagios-check-openmanage-plugin (or just nagios-openmanage-plugin, but
> there are several plugins that use openmanage to check health status on
> Dell hardware). The name is not important to me, but I prefer if we
> could agree on common naming.
>
> > But maybe its better to not add every plugin into a new
> > package. Unfortunatly I'm currently swamped with icinga, check_mk and
> > nagios3. Would somebody else maybe build a skeleton for a general
> > package including several plugins.
>
> I agree that this could be a good idea for plugins that are simply a
> script without their own Makefile or similar.

Not at all. With source format 3.0 you can have more than one upstream 
tarball. Debian packaging should you also allow to build the "binaries" from 
them in a row, at least theoretical. This should work for non to minimal 
build-deps, maybe also scaling well for bigger projects.
I don't like the idea to have a bunch of binary packages (at least source 
packages) shipping only one or two plugins, I guess ftp-master feels the same.

> > My current ideas are as follows (others: feel free to add more ideas):
> >
> > * Name: nagios-plugins-extra
>
> We could split this in two binary packages (one for plugins that you
> mainly use on the Nagios server and another for plugins that would also
> be useful on Nagios "clients"). This is the same as nagios-plugins-basic
> and nagios-plugins-standard, except that at least I had to read the
> package descriptions to understand the latter two. :)

The different between the packages is based on the depencies footprint (the 
basic packages has less) and the common use cases, not really on the location, 
where you could use them.

IMHO in the beginning, when we would have just a couple of plugins in there, 
we should avoid to clutter into serveral binary packages.

> > * Description should contain the included plugins (oneliner should be
> >   enough)
> > * Copyright should list every plugin
>
> I guess we should also have a list which includes plugin name, homepage
> for plugin, where to download, and version included in the package. Does
> debian/watch support multiple entries?

Have a look into #531321.

With kind regards, Jan.
-- 
Never write mail to <waja at spamfalle.info>, you have been warned!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
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: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-nagios-devel/attachments/20100325/2f91d017/attachment.pgp>