Mediation needed for munin-node and munin-main

[Kris Kennaway]

On Thu, Dec 09, 2004 at 06:26:34AM +0100, Lupe Christoph wrote:
> 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.

How time-consuming?

> 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.

I meant 'installed and immediately deinstalled', i.e. leave nothing
behind if nothing is changed from the default installation.  If the
administrator changes something, it should be preserved after
deinstallation.  This is how ports are supposed to work.

> 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 at 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 |
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20041209/2d260457/attachment.bin