From owner-freebsd-hackers Wed Oct 3 22:12:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kzsu.stanford.edu (KZSU.Stanford.EDU [171.66.118.90]) by hub.freebsd.org (Postfix) with ESMTP id 4B9C637B401 for ; Wed, 3 Oct 2001 22:12:32 -0700 (PDT) Received: (from romain@localhost) by kzsu.stanford.edu (8.11.6/8.11.4) id f945CWh39009 for hackers@FreeBSD.ORG; Wed, 3 Oct 2001 22:12:32 -0700 (PDT) (envelope-from romain) Date: Wed, 3 Oct 2001 22:12:32 -0700 (PDT) From: Romain Kang Message-Id: <200110040512.f945CWh39009@kzsu.stanford.edu> To: hackers@FreeBSD.ORG Subject: 4.2 pkg_add/pkg_delete inconsistency Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Has anyone else noticed the following inconsistency? Some packages have been having problems related to @exec and @unexec statements and the %D sequence. I think this happens because contrary to the pkg_create man page, it appears that %D is expanded for @exec, but not for @unexec. (This seems to be a pkg_delete bug, but I haven't been able to look in the FreeBSD CVS server to figure out if/when @unexec last supported %D). @exec needs an absolute pathname, and using %D fulfill this requirement. @unexec commands take place in the directory specfied by @cwd, so leaving off %D seems to be the easiest way for @unexec to access paths that were set up by @exec. To use an example from the database package: @cwd /usr ... npdatabase/dbcheck ... @exec ln -sf %D/npdatabase/dbcheck %D/local/etc/rc.d/dbcheck.sh @unexec rm -f local/etc/rc.d/dbcheck.sh When the package is added: - npdatabase/dbcheck is installed as /usr/npdatabase/dbcheck - /usr/npdatabase/dbcheck is linked to /usr/local/etc/rc.d/dbcheck.sh When the package is deleted: - /usr/local/etc/rc.d/dbcheck.sh is removed Both @exec and @unexec could use just absolute pathnames (/usr/local/etc/rc.d/dbcheck.sh), but this would prevent relocation of the package. It's not important at the moment, but package relocation could be used in the future to help generate system disk images on manufacturing stands without disturbing the manufacturing machine's installed software. Regards, Romain Kang Disclaimer: I speak for myself alone, romain@kzsu.stanford.edu except when indicated otherwise. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message