From owner-freebsd-stable Sun Mar 22 17:01:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11741 for freebsd-stable-outgoing; Sun, 22 Mar 1998 17:01:48 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11723 for ; Sun, 22 Mar 1998 17:01:41 -0800 (PST) (envelope-from doconnor@cain.gsoft.com.au) Received: from cain (localhost [127.0.0.1]) by cain.gsoft.com.au (8.8.8/8.6.9) with ESMTP id LAA28437; Mon, 23 Mar 1998 11:31:08 +1030 (CST) Message-Id: <199803230101.LAA28437@cain.gsoft.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Cy Schubert - ITSD Open Systems Group cc: "Daniel O'Callaghan" , gkshenaut@ucdavis.edu, stable@FreeBSD.ORG Subject: Re: after the release ... In-reply-to: Your message of "Fri, 20 Mar 1998 23:48:52 -0800." <199803210749.XAA15210@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Mar 1998 11:31:08 +1030 From: "Daniel O'Connor" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk > Another consideration: What if somebody modifies the O/S at their > site. MVS, for example, uses USERMODS which automatically get dumped > when patches (PTF's or APARFIXES), or new product (FMID's) are applied. > Would those of us maintaining FreeBSD sites be willing to follow a > regimen as specified by the chosen patch philosophy? On the other hand > would Sun's simpler approach work -- if the file's checksum (MD5?) > doesn't match what the patch expects, abort? Well, that is the whole can of worms IMHO.. I mean if you could guarantee that the system would be in a given state then a binary upgrade would be quite easy. The main problem IMHO would be making a system which didn't mangle any custom stuff you've done to your machine.. I see making a 'patch' consist of a group of things to apply/change/suggest which have pre/co-requisites, and if these are wrong(ie the checksum doesn't match or the date is too new/old) then don't apply that group.. ie make each group atomic, so that if part of it fails, then back the whole group out. --------------------------------------------------------------------- |Daniel O'Connor software and network engineer for Genesis Software | |http://www.gsoft.com.au | |The nice thing about standards is that there are so many of them to| |choose from. -- Andrew Tanenbaum | --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message