Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Dec 2004 13:42:03 -0800
From:      Kris Kennaway <kris@obsecurity.org>
To:        Lupe Christoph <lupe@lupe-christoph.de>
Cc:        ports@freebsd.org
Subject:   Re: Mediation needed for munin-node and munin-main
Message-ID:  <20041208214203.GA10122@xor.obsecurity.org>
In-Reply-To: <20041208094448.GA18514@lupe-christoph.de>
References:  <20041208094448.GA18514@lupe-christoph.de>

next in thread | previous in thread | raw e-mail | index | archive | help

--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 08, 2004 at 10:44:48AM +0100, Lupe Christoph wrote:

> 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.
>=20
> 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.
>=20
> I cannot remove the symlinks.

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.

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.

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

Kris
--SUOF0GtieIMvvwua
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQFBt3UrWry0BWjoQKURAuDrAKDosjDUUQtpd01McuKPgw5y2KK2/ACfbwTU
5U4OOz91f0opvAlRcTmbITE=
=iE8e
-----END PGP SIGNATURE-----

--SUOF0GtieIMvvwua--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041208214203.GA10122>