On Fri, Aug 22, 2008 at 1:05 PM, Sebastian Harl <[EMAIL PROTECTED]> wrote:
> The only sane way to implement this is to have two packages (e.g.
> "-server" and "-client") which conflict each other and provide different
> configurations each (i.e. either rrdtool or network enabled). They would
> both need the collectd binary and the plugins, so that would probably
> have to be split out into an extra package (e.g. "-core") so that we
> don't have to ship that twice. "-server" and "-client" would both depend
> on that. The "collectd" package would then only be a dummy package
> depending on "-server" (i.e. the one with rrdtool enabled), I guess.
> Imho, this is the more reasonable default and preserves the "semantics"
> on upgrades.
That's nice! But I'd maybe name the "-client" as "-agent".
If I understand it correctly: collectd-server would be "the one
receiving data" with a Depends on librrd4 and collectd-core; Then
collectd-(agent|client) would not depend on librrd4 but yes on
collectd-core.
On the default configurations for both packages I'd enable the Listen
& Server lines for the recommended multicast address, that would make
collectd "just work" in a LAN environment! like:
Listen "ff18::efc0:4a42"
I wouldn't make both packages conflict, unless collectd-server
description says "It also provides agent functionallity (as provided
by collectd-agent package)" so people do not try to install both :)
Off topic: how hard would it be to make debconf enable collectd
plugins if the related packages are around (and dependencies?) my
packaging skills are limited to my own python scripts so I don't know
:)
Thanks for all the quick replies ;)
Regards,
Marc
--
http://www.marcfargas.com - will be finished someday.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
