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>