[collectd] "Redesign" of the Debian collectd package

[Sebastian Harl]

Hi Stephan,

Thanks for your feedback!

On Wed, Sep 30, 2009 at 08:04:28PM +0200, Stephan Maka wrote:
> Not sure I understand this scheme; you want to include the rrdtool
> plugin without a dependency on librrd? How is that supposed to work?

Yes and no. All plugins are (and have been since 4.2.0-1) included in
the same package without having a strict dependency (at a package level)
on their individual requirements. The daemon still works if any of those
requirements are missing and will report an error message (without
aborting) at startup. The same will now apply to rrdtool as well.

The reason for handling rrdtool differently in the past was that the
plugin was (unconditionally) enabled by default. With the changes
described in my original E-mail, no output plugin will be enabled in
"collectd-core" (since there is no /etc/collectd/collectd.conf) and the
user will be able to chose the output plugin when installing the
"collectd" binary package - this does not introduce a *strict*
dependency on librrd. If the user chooses to select the "rrdtool" plugin
at install time without having librrd installed, the daemon will start
and complain about not being able to load the plugin. It's then the
user's responsibility to RTFM and install the required packages as
documented in /usr/share/doc/collectd/README.Debian.plugins.

Please note that the new "collectd" package will still recommend all
packages required by any plugin. A novice user (using the default apt*
configuration and thus installing recommended packages by default) will
thus be able to use any plugin without manually installing any further
packages.

> Would it be possible to have an extra package for each plugin? Or at
> least for those with external dependencies, so collectd-core only
> includes cpu, memory, swap, ...?

That's what I used to do until 4.2.0-1. While this does have some
advantages, there are quite a few disadvantages as well:

 * this would produce a whole lot of different packages (23 as of
   version 4.7, three more in 4.8 and possibly another three that are
   currently missing dependencies in Debian; probably many many more in
   the future as more and more specialized plugins make their way into
   collectd)

 * imho that's a mess - from a packaging point of view as well as from
   and archive maintenance POV as well as from a user's POV

 * that separation would be based on _technical_ reasons only which are
   (in most cases) far from being obvious to the user

> Other than that I agree with sensible defaults, ie. collectd shouldn't
> write to disk or send to the network by default. Maybe we can use the
> plugins-{available,enabled}/ scheme for all additional plugins like the
> apache2 package does.

I guess, you're talking about additional plugins provided by additional
packages, right?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090930/cef5c3e3/attachment-0001.pgp