Re: [munin-users] Information to packagers

[Jimmy O. <jo...@li...>]

Once upon a time, Lupe Christoph <lu...@lu...> sagely scribed:
> On Tuesday, 2004-11-23 at 19:48:59 +0100, Jimmy Olsen wrote:
>=20
> > - A new makefile variable -- @@PYTHON@@ has been introduced. The default
> >   is `which python`, so you probably won't have to change this.
>=20
> After giving this some more though, I'm against it. First of all because
> Python is not required for installing Munin. Or running any of it except
> for the smart plugin.

That I added the @@PYTHON@@ variable does _not_ mean that Python should be
a requirement for installing or running Munin. It only means that if
anybody _has_ python, another plugin becomes available.

If Python is not installed, munin-node-configure does the right thing, and
recommends that the plugin not be enabled.

The variable was added so people can override which python is used,
without editing every single plugin by hand.

If you want to hard-code the variable, just create a file with
"PYTHON=3D/usr/local/bin/python", and run make with the additional options
"CONFIG=3Dthe-file-you-just-made". Any variables will then be fetched from
that makefile, while the defaults (for the variables you don't specify in
the file) are the same as normal.
=20
> I also see no reason why this plugin had to be written in a new
> language.=20

It was a contribution. Most plugins are.

> What prevents people from writing plugins in Haskell (dunno if you can
> even *do* that) or Prolog? OK, I grant you this is unlikely. But Ruby
> has acquired some followers. Some stuff I use on FreeBSD is written in
> Ruby.

Absolutely nothing prevents this, and such plugins will be accepted into
the package.

The only plugin that was rejected because of language, was partly written
in C, and it was rejected because we didn't want to complicate things by
having to compile. (That plugin was later resubmitted as a perl-only
version, which was then included into the distro.)
=20
> This is a good example of a plugin that should go in a contrib
> directory.=20

A lot of the plugins in the package are marked contrib. Munin operates
with three "families" of plugins:

* auto - Supported plugins that are should be auto-probed on install
* manual - Supported plugins that should not be auto-probed, as they are
  only useful to some poeple.
* contrib - Unsupported plugins that should not be auto-probed on install.
* snmpauto - SNMP plugins that should be probed when you SNMP probe a
  host/network.

Try the following commands to list the different plugins:

munin-node-configure --families=3Dauto
munin-node-configure --families=3Dmanual
munin-node-configure --families=3Dcontrib
munin-node-configure --families=3Dsnmpauto

> Including it with the other plugins means we have to support
> it.=20

In this specific case, the smart_ plugin is in the auto family. This means
that people can expect bugs in it to be fixed, and it means that
munin-node-configure --shell (that is often run on install) will
probe to see if it should be used.

It does _not_ mean that the munin-node packages should go to great lengths
to make sure that the plugin has everything it needs to run. If python is
installed, and your harddrives are SMART capable, the plugin will be used.
If not, it won't.

> As I said, I don't know Python. And I have no time to learn it. So
> what do I do when somebody encounters a problem on FreeBSD with this
> plugin? I feel resposible for all of Munin on FreeBSD, not just the
> stuff I wrote.

Don't do that. It just causes early gray hairs. :-P

If any bugs pop up, we'll get them fixed somehow. I don't have access to
Solaris boxes nowadays, but I still included the Solaris plugins when they
were contributed. The same goes for AIX. There have been several bugs in
both groups of plugins, which we've managed to get fixed.


-jo :-)