From owner-freebsd-current  Sat Dec  7 09:10:41 1996
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id JAA01101
          for current-outgoing; Sat, 7 Dec 1996 09:10:41 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA01096
          for <freebsd-current@freebsd.org>; Sat, 7 Dec 1996 09:10:39 -0800 (PST)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id JAA22069 for <freebsd-current@freebsd.org>; Sat, 7 Dec 1996 09:10:42 -0800 (PST)
>To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: freebsd-current@freebsd.org (FreeBSD-current users)
Subject: Re: cvs commit: src/include utmp.h 
In-reply-to: Your message of "Sat, 07 Dec 1996 14:07:57 +0100."
             <199612071307.OAA18895@uriah.heep.sax.de> 
Date: Sat, 07 Dec 1996 09:10:42 -0800
Message-ID: <22065.849978642@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> Breaking backward compatibility to ourselves is IMHO a Bad Thing.  I
> volunteer to write that tool (i think it's not a big deal anyway), but
> where should it go to?

Ah, that's the harder part of the solution, isn't it? :-)

Upgrades in general are poorly handled and always have been.  To
really support this properly would require several enhancements to our
release building and installation systems:

1. The distributions you install at or after installation time
   should be recorded someplace so that you know what needs upgrading
   in coarse general terms.

2. The mutable components of /etc made more friendly to automated
   merges, this going as well for any system directory the average 
   user is likely to modify.

3. The idea of a "delta distribution" on either local or remote media
   integrated along the lines of CTM, where running statistics on
   where you "are" vs where the deltas would like you take you
   handling much of the process of what we refer to as upgrading.

   One of these upgrade-time actions could, in this case, be the
   migration of your wtmp file for instance.

The actual wtmp converter is the very simplest part of the exercise,
and it's the framework we'll be far more needing before an upgrade
will ever be even close to painless. :-)

					Jordan