From owner-freebsd-ports@FreeBSD.ORG Wed Dec 8 21:35:38 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 133C416A4CE for ; Wed, 8 Dec 2004 21:35:38 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9CB343D48 for ; Wed, 8 Dec 2004 21:35:37 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 21D6F51385; Wed, 8 Dec 2004 13:42:04 -0800 (PST) Date: Wed, 8 Dec 2004 13:42:03 -0800 From: Kris Kennaway To: Lupe Christoph Message-ID: <20041208214203.GA10122@xor.obsecurity.org> References: <20041208094448.GA18514@lupe-christoph.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20041208094448.GA18514@lupe-christoph.de> User-Agent: Mutt/1.4.2.1i cc: ports@freebsd.org Subject: Re: Mediation needed for munin-node and munin-main X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 21:35:38 -0000 --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--