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
signature.asc
Description: Digital signature
_______________________________________________ collectd mailing list collectd@verplant.org http://mailman.verplant.org/listinfo/collectd