From owner-freebsd-hackers  Sun Jun 25 07:44:09 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id HAA22422
          for hackers-outgoing; Sun, 25 Jun 1995 07:44:09 -0700
Received: from whisker.internet-eireann.ie (whisker.internet-eireann.ie [194.9.34.204])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA22410
          ; Sun, 25 Jun 1995 07:44:00 -0700
Received: from localhost (localhost [127.0.0.1]) by whisker.internet-eireann.ie (8.6.11/8.6.9) with SMTP id PAA12103; Sun, 25 Jun 1995 15:44:29 +0100
To: Warner Losh <imp@village.org>
cc: Network Coordinator <nc@ai.net>, "Jordan K. Hubbard" <jkh@FreeBSD.ORG>,
        hackers@FreeBSD.ORG
Subject: Re: Announcing 2.0.5-950622-SNAP 
In-reply-to: Your message of "Sun, 25 Jun 1995 00:21:32 MDT."
             <199506250621.AAA02309@rover.village.org> 
Date: Sun, 25 Jun 1995 15:44:29 +0100
Message-ID: <12101.804091469@whisker.internet-eireann.ie>
From: "Jordan K. Hubbard" <jkh@FreeBSD.ORG>
Sender: hackers-owner@FreeBSD.ORG
Precedence: bulk

> Some are easy:  New binaries and Libraries.  You copy the new ones in,
> reboot, and you are set.  Ditto the kernel, kinda.  The format of the
> kernel config file sometimes changes, and you need to be able to
> translate old config files to the new ones.  This is usually easy.

This can be generalized a little more by simply saying that for every
level of "update" you may need to outright replace certain files and
possibly patch others in place.

Which brings up two things I didn't cover in my previous message and
that's one, the issue of MD5 checksumming the old ones so that you can
tell if the user _modified_ the other one and may want the choice of
either not updating it or moving it to a specified location and two,
"grouping" the deltas in such a way so that a given update can be
expressed as <n> individual deltas without losing the granularity (if
you wanted to back out an individual update, it could do it properly
by un-applying all the relevant deltas).  One example of this would be
a kernel change where the routing structures were modified.  You'd
want to replace the kernel, routed, route, netstat, etc. all in one
update operation.

> Then you get into the thornier issues:  /etc/rc* and /etc/netstart.
> From time to time, things need to be added to these file, and you want
> to preserve, as much as possible, the configuration that has been
> made here.

Well, this has been simplified to a great extent by /etc/sysconfig.
It's my intention that ALL of the mutable files in /etc eventually
collapse to just /etc/sysconfig, and there's never any reason at all
for the user to modify the others.

> This doesn't address the "dual boot" issue.  In that case, you'd want
> to be able to say "Install the system onto that other device, and use
> my current system as a template."  It also doesn't address the "ooop,
> that was stupid, I want to go back now." either.

Dual boot, no and possibly never.  The "oops, I want to go back now"
was covered in my previous message.

						Jordan