From owner-freebsd-current@FreeBSD.ORG Tue May 6 17:09:53 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 1D07737B404 for ; Tue, 6 May 2003 17:09:53 -0700 (PDT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B1F043F85 for ; Tue, 6 May 2003 17:09:52 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.9/8.12.9) with ESMTP id h4709oiJ031672; Tue, 6 May 2003 20:09:50 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030507083913.Y18014@gamplex.bde.org> References: <3EB8109D.2060307@isi.edu> <20030507083913.Y18014@gamplex.bde.org> Date: Tue, 6 May 2003 20:09:49 -0400 To: Bruce Evans , Lars Eggert From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 cc: current@freebsd.org Subject: Re: 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 00:09:53 -0000 At 8:50 AM +1000 5/7/03, Bruce Evans wrote: >On Tue, 6 May 2003, Lars Eggert wrote: > > > I'm putting a script together that will remove stale pieces > > after an installworld, and my find+mtime approach chokes, > > because some uses of ${INSTALL} in the Makefiles hardcode > > the -C argument, [...etc...] > > > > Can the -C be removed without ill effects? > >-C is important for includes because it prevents most executables >(including freshly built ones) becoming out of date every time >you install includes. > >-C is used for very important executables like ld-elf.so.1 >for its side effect of giving an atomic-as-possible install. >Atomic-as-possible installs should be the default, and >install(1) has made some progress towards this, but it is not >there yet -- by default, it still begins with unlinking the >target. I think this "remove stale pieces" issue is one that we have to find a decent solution to, because it keeps popping up every few months (in slightly different contexts), and it's going to drive us all nuts. I made a few stabs at trying to implement a solution, and but I never trotted those out because the results were not particularly appealing. 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. My next thought is that install-log file could get pretty large and unwieldy. In order to keep that a reasonable size, it might make sense to have 'install' only write a line to that log file if it was asked to install the file, but if after the install process the last-mod-time on the file is not "recent enough" (for whatever reasons, such as -C or -p). We could then write a process that goes thru all of whatever- directories-we-care-about, have it ignore all files with a "recent" last-change-time, and then look into this log file for any of the remaining filenames. At the moment, I think this is the most promising and least- disruptive solution to the stale-files problem. Everything in the buildworld/installworld process should (I hope) be exactly the same as it is now, with all the same options that are available now, except you would have the option of generating this one additional file. Then, with the combination of a new program and this one additional file, the end user could track down what files are stale. I think it's important that we come up with a solution that can be used by anyone, and not a solution that forces a restriction on what options can be given to the 'install' commands. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu