[collectd] "Redesign" of the Debian collectd package

XANi xani666 at gmail.com
Sat Oct 10 11:17:04 CEST 2009


> >> Okay, I understand your reasons. It would just be nice to say: on
> >> this host I additionally install collectd-rrdtool, it starts
> >> writing rrd files out of the box and the whole dependency mountain
> >> gets cleaned away if I change my mind and uninstall it.
> >
> > Hrm … the only way, I can think of, to implement that, would be to
> > introduce a new binary package for each plugin (with external
> > dependencies). See my previous E-mail, why I do not want to
> > implement that. Any other ideas how to do that would be very
> > appreciated.
> >
> 
> 
> How about following apache2's model ? Have collectd package with the
> most used plugins like mem/cpu/disk/etc bundled in and have either a
> collectd-extra package or multiple
> collectd-foo for different plugins. Same for directory structure - I
> really like de mods-available/mods-enabled thing.
collectd-foo would equal to probably 30 or so plugins, each one having
few kbs. It would make installing deps little faster but then most ppl
would just install collectd-all or something like that so it's more to
do for maintainer for no real gain

About config layout, "apache-alike" is good for bigger/more complicated
installs when u for example have 2-3 page long postgresql or snmp
plugin config, while "one big file" is (i think) better for most
installations.

Ideal would be something like exim4-config, in the end of configuring
it asks if u want to have one big file or lots of small ones

Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20091010/9847ec7c/attachment.pgp 


More information about the collectd mailing list