Date: Thu, 9 Dec 2004 06:26:34 +0100 From: Lupe Christoph <lupe@lupe-christoph.de> To: freebsd-ports@freebsd.org Subject: Re: Mediation needed for munin-node and munin-main Message-ID: <20041209052634.GX3113@lupe-christoph.de> In-Reply-To: <20041208214203.GA10122@xor.obsecurity.org> References: <20041208094448.GA18514@lupe-christoph.de> <20041208214203.GA10122@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 2004-12-08 at 13:42:03 -0800, Kris Kennaway wrote: > On Wed, Dec 08, 2004 at 10:44:48AM +0100, Lupe Christoph wrote: > Why not? The usual way to handle removing "configuration items" (be > they files, or in this case symlinks) is to test whether the installed > configuration is identical to the default configuration, and only > remove them if so. The default set is determined by running munin-node-configure which loads each plugin in turn and asks it if it can autoconfigure and if it is a generic plugin (e.g. if_) about suggested suffixes. This is quite time-consuming. And it varies depending on the hardware, so if a machine is changed, the plugins may change. I would have to make a snapshot of the plugins at initial install. If the plugin list has not been changed from that, I remove it. That makes the deinstall unstable - sometimes it removes plugins sometimes it doesn't. I didn't like removing unchanged config files, and I like this much less. It violates the law of least astonishment. > For example, at install-time you'd create the symlinks if they don't > already exist (i.e. no previous installation of the package), and at > deinstall-time you'd read the destination of the symlinks, test > whether they're still pointing to the default location, and remove > them if so. Thus, if the user has changed the defaults they'll remain > untouched, but if they haven't changed them then the system will be > cleaned up. This does not work. The symlink always have the same destination. They are only added or deleted by the user. > It's an important requirement that doing 'make install deinstall' > (alternatively pkg_add; pkg_delete) leaves the system in the same > state it was before the 'install', and not leave behind random cruft > in ${PREFIX}. Well, I need at least VERSION. And the user would not like munin-main to delete all the data files that have been accumulated while the port was installed. I cannot ask the user if he wants all files deleted with a default of "yes" because many people will just blindly hit return. And if the default is "no", the automated removal will leave "cruft" behind. The only solution I see is to detect that the package is installed in a test environment and change the behaviour to remove everything. This means that the test is not realistic anymore, but will pass. You probably wont like that. 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?20041209052634.GX3113>