From owner-freebsd-current@FreeBSD.ORG Tue May 6 18:56:26 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DF2D37B401 for ; Tue, 6 May 2003 18:56:26 -0700 (PDT) Received: from aeimail.aei.ca (aeimail.aei.ca [206.123.6.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FF7443F3F for ; Tue, 6 May 2003 18:56:25 -0700 (PDT) (envelope-from anarcat@anarcat.ath.cx) Received: from shall.anarcat.ath.cx (e04w86gm73gla8hs@dsl-133-253.aei.ca [66.36.133.253]) by aeimail.aei.ca (8.11.6/8.10.1) with ESMTP id h471uN718963; Tue, 6 May 2003 21:56:23 -0400 (EDT) Received: from lenny.anarcat.ath.cx (lenny.anarcat.ath.cx [192.168.0.4]) by shall.anarcat.ath.cx (Postfix) with SMTP id 2E219318; Tue, 6 May 2003 21:56:22 -0400 (EDT) Received: by lenny.anarcat.ath.cx (sSMTP sendmail emulation); Tue, 6 May 2003 21:56:48 -0400 Date: Tue, 6 May 2003 21:56:48 -0400 From: The Anarcat To: Garance A Drosihn Message-ID: <20030507015648.GB692@lenny.anarcat.ath.cx> References: <3EB8109D.2060307@isi.edu> <20030507083913.Y18014@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i cc: Lars Eggert cc: current@freebsd.org Subject: Stale pieces in the base system? (was: hardcoded -C argument to ${INSTALL}) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 01:56:26 -0000 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =2E..impossible! :) On Tue May 06, 2003 at 08:09:49PM -0400, Garance A Drosihn wrote: >=20 > Here is my current idea, but I have not had time to try and > implement it. Modify 'install' to have some kind of log-file > capability. Whether or not 'install' changes the destination, > it *does* know that it was asked to change that destination, > and could write a line out to a log file for that. I too had an obscene idea like this, but it was much more perverse and powerful: Why don't we make that install program record the files in a package? install(1) (or pkg_install progs) would then know which files would be where. By bumping a serial or version number somewhere, you could check which files have been changed/added/removed quite easily. I recently posted a rather obtuse comment about "shutting the hell up" on a similar topic, and I threatened the world of hacking my way through the Mk files to make bsd.{prog,lib}.mk register through the package system. Well, what I ended up was that odd mess of Makefile magic and pkg_create voodoo that didn't actually do much except registering PROG and FILES. I also discretely advocated for the packaging and splitting of the base system and it's then that this strange feeling appeared, that install(1) wasn't doing all it could for us. What we need is a pkgAPI. Folks on both binup and libh projects ended up saying the same thing. Actually, what we need is libpkg. A common interface to the inner guts of pkg_create, pkg_add but mostly ports/Mk/*.mk magic. Implementing pkg-interaction functions to install would then be a breeze. Otherwise, it would be a waste of time. The way I see it, we could add a new flag (eek!) to install that would be -n or (better) -P and that would be a Package Name under which to record the files installed. Heck, this could even work in ports! Most ports out there use some INSTALL_FLAGS or another... By default, this Package Name would be simply "base", so that everyone would be happy and backward compatibility would be simple. Otherwise, if the -P flag would be given, install(1) would try to register the installed files to the given package. Package version, of course should be guessed. ;) There is the problem of the ports that would have to be massively patched at that point, but I think it would be feasable. So if you folks keep on coming back to this topic without actually posting out patchsets or concrete stuff, I'll actually implement this crazy idea, and you won't have anything more to bikeshed about. Na! A. --=20 Seul a un caract=E8re scientifique ce qui peut =EAtre r=E9fut=E9. Ce qui n'= est pas r=E9futable rel=E8ve de la magie ou de la mystique. - Popper, Karl --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+uGffttcWHAnWiGcRAoQgAJ4kLkYqCg6pBisqijX1rVnM0QFqCwCePz/3 LXCYLGcDLhDEbTJIOz9Ycys= =qHtv -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi--