From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 14:05:01 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 7B5DD16A4BF; Mon, 1 Sep 2003 14:05:01 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7872D43FE0; Mon, 1 Sep 2003 14:05:00 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h81L4xTX028847; Mon, 1 Sep 2003 15:04:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 01 Sep 2003 15:03:57 -0600 (MDT) Message-Id: <20030901.150357.118092347.imp@bsdimp.com> To: DougB@freebsd.org From: "M. Warner Losh" In-Reply-To: <20030901122624.A6074@znfgre.qbhto.arg> References: <20030901015535.Y3776@znfgre.qbhto.arg> <20030901.102216.108348004.imp@bsdimp.com> <20030901122624.A6074@znfgre.qbhto.arg> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 21:05:01 -0000 In message: <20030901122624.A6074@znfgre.qbhto.arg> Doug Barton writes: : 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! :) Maybe I was a little strong in what I said. : 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. We need to keep some database. Either incrementally as we go, so that we know all that belongs in certain directories (which is risky because some third party software installs stuff into them), or we need to keep track of what we've shipped in the past so we can remove it when it is obsolete. Your solution kills the ability to keep old libraries around in /usr/lib/compat, for example, without freshly installing them every time. : 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. Right now it is a set of tools that can be used to build a database of files that FreeBSD used to have, but doesn't any more. This is the most conservative approach that we can take. Given the unknown nature of most systems, I think we need to be conservative here. Also, it doesn't move things out of the way in such a way that's hard to recover from should things go wrong in the middle somewhere. This list of files can be moved or removed, that nit doesn't really matter and is really an uninteresting part of the problem: let the user decide. The hard part is coming up with this list. : > 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. /usr/include isn't too bad, and /usr/share/man is obviously completely safe since the man pages are available on the web and assuming no third party software. /usr/lib is very dangerous and can result in weird things happening, especially for the case where something bad happens while installworld is running. : 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. :) Yes. I hope to have something by BSDcon to show to people. Work has kept me busier than I'd have liked, and the remaining time has been soaked up by getting NEWCARD in better shape for 5.2. Warner