Date: Wed, 8 Dec 2004 10:44:48 +0100 From: Lupe Christoph <lupe@lupe-christoph.de> To: ports@freebsd.org Subject: Mediation needed for munin-node and munin-main Message-ID: <20041208094448.GA18514@lupe-christoph.de>
next in thread | raw e-mail | index | archive | help
Hi, folks! Since Sergey Matveychuk and I can't agree on how munin-node should behave, we agreed ;-) to defer to the ports mailing list. Please tell me how you would handle Munin. Sorry for the long post, but I would rather dump all you might want to know at once than answer lots of questions. I guess there still will be some. The issue is that the deinstall of both munin-node and munin-main leaves files behind. In the case of munin-main they are created by a cron job, so a test install may see them or not. Let me give you some background about Munin. Munin is a distributed system that gathers performance data and generates webpages with graphs with the help of RRDtool. There are two components, the gatherer which only needs to run on one system (the munin-main port), and the collector that extracts information from one system using a very simple plugin architecture (the munin-node port). The Munin node uses a daemon process that has a few config files, and a plugin directory. All files in that directory that fulfill some criteria are used as plugins. Since there is a lot of plugins, not all of them are useable or relevant for a given system. In order to be able to make all of them available for the user and let them choose, Munin uses symlinks that point to the plugins. Some plugins have names like xxx_. Those parse the name they are called with (e.g. xxx_yyy) and use the last part as an argument. This could be the name of an interface. So the symlinks are configuration. The port follows the example of the Debian package in automatically installing plugins if there was no pre-existing set. It also installs a VERSION file that allows it to install recently added plugins on an upgrade. I cannot remove the symlinks. I could skip installing the default set, making munin-node a bit more difficult to manage for the user. But I still have to have this VERSION file. The same problem exists for munin-main. I could skip installing the cronjob, making the port less friendly, creating more pitfalls for the user. Mathieu Arnold suggested I ask this mailing list. I did http://docs.freebsd.org/cgi/mid.cgi?20040303100543.GW2562 but received no help. Now I ask again because Sergey and I can't agree. Mathieu agreed that adding a message to pkg-plist would do. This message has evolved over time, and I missed adding it to munin-main until recently. But it seems this will not placate Sergey :-P So I have to ask again: what is the accepted way of dealing with files that are needed for an upgrade or that will be precious to the user? Sorry for wasting time and bandwidth. Lupe Christoph -- | lupe@lupe-christoph.de | http://www.lupe-christoph.de/ | | "... putting a mail server on the Internet without filtering is like | | covering yourself with barbecue sauce and breaking into the Charity | | Home for Badgers with Rabies. Michael Lucas |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041208094448.GA18514>