From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 12:42:23 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 7D58316A4BF; Mon, 1 Sep 2003 12:42:23 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2116543FBF; Mon, 1 Sep 2003 12:42:22 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23](untrusted sender)) by comcast.net (sccrmhc12) with SMTP id <200309011942200120027tpue>; Mon, 1 Sep 2003 19:42:21 +0000 Date: Mon, 1 Sep 2003 12:42:19 -0700 (PDT) From: Doug Barton To: "M. Warner Losh" In-Reply-To: <20030901.102216.108348004.imp@bsdimp.com> Message-ID: <20030901122624.A6074@znfgre.qbhto.arg> References: <20030901072017.GH30277@sunbay.com> <20030901.012249.118997606.imp@bsdimp.com> <20030901.102216.108348004.imp@bsdimp.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: kuku@physik.rwth-aachen.de cc: current@freebsd.org Subject: Re: /lib symlinks problem? 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: Mon, 01 Sep 2003 19:42:23 -0000 On Mon, 1 Sep 2003, M. Warner Losh wrote: > In message: <20030901015535.Y3776@znfgre.qbhto.arg> > Doug Barton writes: > : On Mon, 1 Sep 2003, M. Warner Losh wrote: > : > : > My tool is initially just a 'delete these files' tool, but now that I > : > think about it, it wouldn't be hard to say also 'create these > : > symlinks'. The hard part here is generating the 'obsolete' lists. > : > : I posted one approach to this today... touch a file right before you > : start installworld, then consider anything not newer than that file a > : candidate for disposal. There is currently something weird going on in > : /usr/lib though... a lot of the files don't have newer dates, I haven't > : tracked down why yet. > > No. That's not what I'm talking about. That approach is crap, > because installworld doesn't touch all files. Please tell us how you really feel! :) I have never said that my suggestion was a complete solution to the problem. But it does get you pretty far down the road for any given instance of installworld, without needing to maintain complicated databases of what files have been installed by the system. I would think that using my suggestion in directories where we _do_ touch every file (like *[s]bin) would make your task easier, but since I haven't seen your WIP yet, I'll reserve further comment till I do. > : Also, I highly recommend NOT deleting the files, but moving them > : somewhere. This makes it much easier to recover if you delete something > : you shouldn't have. > > I don't care the method of removal. I care more about the list. If > you want to mv them them instead of rm, it isn't a big deal to change > that detail. Ok, consider this a request to do that then. As suggestions, I currently use two different methods to deal with this. In the after_installworld script I posted, I create an 0ld directory in the same directory as the files I want to back up. I use zero as the first character so it always sorts at the top for easy identification. For mergemaster's -P option, I create /var/tmp/mergemaster/preserved-files-yymmdd-hhmmss, where the time is the time that the run of mergemaster started. Both approaches have merit. For binaries and libs my thinking was that leaving them on the same file system will make it possible to recover if one of the things you happened to mv turned out to be important during mount time/boot time. > The mv /usr/foo -> /usr/foo.old is too dangerous, and I think it is > the wrong way to go. Well, I started doing it for /usr/include and /usr/share/man personally because nothing from either directory is needed for installworld, and I know for a fact that I'm rigorous about not putting any foreign stuff in there. I'm certainly not married to the idea of doing it that way. As I've been saying all along, the stuff I've been posting is little more than Proof of Concept work atm. My goal has been to defeat the inertia surrounded by "we cannot make this work!" by demonstrating one method that does work, albeit imperfectly. The fact that you're moving farther down this road is music to my ears. :) Doug -- This .signature sanitized for your protection