Date: Sun, 25 Jun 1995 15:44:29 +0100 From: "Jordan K. Hubbard" <jkh@FreeBSD.ORG> 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 Message-ID: <12101.804091469@whisker.internet-eireann.ie> In-Reply-To: Your message of "Sun, 25 Jun 1995 00:21:32 MDT." <199506250621.AAA02309@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12101.804091469>