From owner-freebsd-arch@FreeBSD.ORG Thu Jun 12 00:31:25 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0284D37B401; Thu, 12 Jun 2003 00:31:25 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28EE743FDD; Thu, 12 Jun 2003 00:31:24 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5C7VLaK011743; Thu, 12 Jun 2003 00:31:21 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5C7VJOX011742; Thu, 12 Jun 2003 00:31:19 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 12 Jun 2003 00:31:19 -0700 From: David Schultz To: "Greg 'groggy' Lehey" Message-ID: <20030612073119.GA11366@HAL9000.homeunix.com> Mail-Followup-To: Greg 'groggy' Lehey , Doug Barton , ache@nagual.pp.ru, Alexey Zelkin , arch@freebsd.org References: <20030610124747.A7560@phantom.cris.net> <20030610024524.D23396@znfgre.qbhto.arg> <20030611075750.GB57496@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030611075750.GB57496@wantadilla.lemis.com> cc: ache@nagual.pp.ru cc: Doug Barton cc: Alexey Zelkin cc: arch@FreeBSD.ORG Subject: Re: removing stale files (was: Re: cvs commit: src/etc Makefile locale.alias locale.deprecated nls.alias) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 07:31:25 -0000 On Wed, Jun 11, 2003, Greg 'groggy' Lehey wrote: > On Tuesday, 10 June 2003 at 2:53:09 -0700, Doug Barton wrote: > > On Tue, 10 Jun 2003, Alexey Zelkin wrote: > > > >> [moved to -arch] > >> > >> Well. Then I have to rehash $subj issue again. There's important > >> point with removing old (currently unsupported, or correctly to say > >> -- partly supported) locales. They should be removed at installworld > >> stage. > > > > I think that's a better way to do it. This same topic of removing stale > > files at installworld time has been discussed before, and it seems to be > > the least evil solution. > > Agreed. > > I think we should work towards a policy where we say "these > directories belong to the system. Don't install your own things there > until you know exactly what you are doing.". That would greatly > simplify the job of keeping things up to date. I like this idea, too, but unfortunately, it seems to be too contentious to move forward with as is. (This has been discussed before.) It also doesn't solve the problem that mergemaster often requires significantly more intervention than it should. Another idea is to develop a simple API that would make it easy for the folks developing new features to write ``upgrade scripts''. Think of this as a smart mergemaster on steriods. The appeal of this approach is that configuration files could be automatically patched, and specific crufty files could be automatically deleted. Such an API should support the following features: - Every upgrade operation can be undone until the administrator specifically requests that the backup files be destroyed. - Upgrades can be classified by ``risk level'', which is the estimated likelihood that the change is so nontrivial that the automatic upgrade will fail. - The upgrade process will clearly report exactly what changes have been made and associate a unique identifier with each ``transaction.'' Developers would be encouraged, but not required, to write these trivial specifications when they make changes that will affect the upgrade process, and there are only a few such changes per release. (Only upgrading between releases or security branches needs to be supported.) To give an example of what I mean: update uucp { desc = "Remove UUCP from the base system"; bsdversion = 500000; // or whatever it is risk = 4; // of 10 action { remove bin/uucp bin/uuname [...] ; } } update etc_debuglog { desc = "Introduce debug.log which gets debug.*" bsdversion = 501100; risk = 6; action { // We wouldn't use ed in the real thing, but the // specific choice would be up to the person // writing the spec...probably patch(1) in some cases update etc/syslog.conf { ed etc/syslog.conf <