Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Jun 2003 00:31:19 -0700
From:      David Schultz <das@FreeBSD.ORG>
To:        "Greg 'groggy' Lehey" <grog@FreeBSD.ORG>
Cc:        arch@FreeBSD.ORG
Subject:   Re: removing stale files (was: Re: cvs commit: src/etc Makefile locale.alias locale.deprecated nls.alias)
Message-ID:  <20030612073119.GA11366@HAL9000.homeunix.com>
In-Reply-To: <20030611075750.GB57496@wantadilla.lemis.com>
References:  <20030610124747.A7560@phantom.cris.net> <20030610024524.D23396@znfgre.qbhto.arg> <20030611075750.GB57496@wantadilla.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <<EOF
				15a
				*.debug		/var/log/debug.log
				.
				wq
				EOF
			}
		}
	}

	update remove_old_locales {
		[...]
	}

The main selling points / buzzwords here are:

- fully general; won't have to solve the problem again
- less mergemaster work for sysadmins, harder to screw up
- can always fall back on mergemaster when appropriate
- conservative
- users can select which updates they want on a per-change
  (transaction) rather than per-file basis, or just ask for
  the defaults at risk level N
- ``It just works.''



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030612073119.GA11366>