Hi Joe, On Fri, May 15, 2009 at 03:10:21PM -0400, Moore, Joe wrote: > The claims in this bug dialog that "a collectd package without rrdtool > is non-functional" are simply wrong.
I did not claim that the package would be non-functional. I said that the _default_ installation would not provide any _useful_ functionality. > There are several collectd storage backends, of which RRD is only one. > In particular, it has the ability to export to CSV files, or to a > network collectd server. Right ... however, CSV is _far_ from being a reasonable default and the network plugin requires manual configuration to be useful. RRDtool is the only plugin that properly works out of the box with a default configuration. That's why I chose to use it as the default output plugin. Now, I fully see and agree with your point that there are setups that do not require and want RRDtool (on some hosts at least). The reason why I did not yet provide a solution for this bug report is that I want to do it right and I did not yet come up with a solution that I like. > With the Depends: as it currently sits, installing collectd (and the > required librrd4) can create RRD data files, but since rrdtool itself > in only in the Recommends:, there's no way to get the data out of > those files, so it's kinda pointless to save data in that format. Well, collectd is about putting data _into_ those files. You need different software (or manually install the shipped example files) to get data out of it. So, imho, recommending rrdtool is perfectly valid and fine (after all, rrdtool is by far the most common way to store data collected by collectd, be it on a "client" or "server" - that's why it's recommended rather than suggested only). > "The Depends field should be used if the depended-on package is > required for the depending package to provide a significant amount of > functionality." With the current default configuration, rrdtool _is_ required. > IMO, someone who's trying to minimize a server installation base (by > Install-Recommends="0";) would be considered an "unusual > installation". Under normal use (installing Recommends) there would > be no difference from the current condition. > > Although the RRDtool plugin would need to be commented out by the > delivered conffile collectd.conf. ... which would however render the _default_ configuration non- functional. I.e. a user would _have_ to edit the configuration to get something out of collectd which, imho, is not an option. > Perhaps when SID is updated with collectd 4.7.0, the Depends: could be > changed? I am working on that and as soon as I come up with something I like, I will implement it. I'm sure there will be a solution to this long before Squeeze. That solution would have to fulfill the following criteria: * Be flexible - a user should be able to make use of the full flexibility offered by collectd itself. * Be scalable - a user should be able to _easily_ use the package on a small embedded device as well as in large network environments. * Offer a working default configuration. A user who simply wants to try out collectd should be able to do 'apt-get install collectd' and be happy. However, still make it easy to adopt the configuration to special needs. * Try to avoid dependencies. * When splitting the 'collectd' package, the resulting packages ought not conflict with each other. E.g. a "transition" from a "client" to a "server" package should be possible without solving conflicts between packages or even configurations. Since I knew I wouldn't be able to solve all of that for Lenny (we were in deep freeze already), I did not rush into something I would regret later on but decided to come up with a good solution. What I'm currently aiming at is something along the following lines: * Split the 'collectd' binary package into 'collectd-core' and 'collectd'. * 'collectd-core' would provide the collectd binaries and plugins but _no_ configuration. The package would recommend (or possibly even suggest) all plugin dependencies. * 'collectd' would provide the same configuration as it does now and depend on librrd. Obviously, this package would have to depend on 'collectd-core'. This way, people upgrading collectd would not see any difference, i.e. their setup would still work just like before. They could, however, remove the 'collectd' package (but keep 'collectd-core') to be able to drop the dependency on 'rrdtool'. A new user installing the 'collectd' package would get a working default configuration. People with more complex setups could install 'collectd-core' only and would not be required to install any additional dependencies. In addition to that, I'd like to make it easy to create further packages providing rather special configuration, e.g. with networking enabled by default. This would be somewhat similar, in spirit, to the exim4- daemon-* packages. This would make it possible to provide default configurations for common use-cases in Debian and make it possible for local administrators to easily manage their own configuration. I'm not yet sure though if that makes sense and how to properly implement it. Since this is mostly about configuration handling, this is related to the last third of my last E-mail [1]. Any comments, further ideas and discussion would be very appreciated. Thanks for your interest! Cheers, Sebastian [1] http://bugs.debian.org/495936#35 -- 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
