From owner-freebsd-stable Mon Mar 23 11:43:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22143 for freebsd-stable-outgoing; Mon, 23 Mar 1998 11:43:43 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21998 for ; Mon, 23 Mar 1998 11:43:08 -0800 (PST) (envelope-from cschuber@passer.osg.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id LAA07832; Mon, 23 Mar 1998 11:42:20 -0800 (PST) Message-Id: <199803231942.LAA07832@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaaodla; Mon Mar 23 11:42:16 1998 X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: Cy Schubert - ITSD Open Systems Group X-Sender: cschuber To: "Daniel O'Connor" cc: Cy Schubert - ITSD Open Systems Group , "Daniel O'Callaghan" , gkshenaut@ucdavis.edu, stable@FreeBSD.ORG Subject: Re: after the release ... In-reply-to: Your message of "Mon, 23 Mar 1998 11:31:08 +1030." <199803230101.LAA28437@cain.gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Mar 1998 11:41:25 -0800 From: Cy Schubert - ITSD Open Systems Group 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. If a user modification to the system has been logged and MD5 or some other checksum is used, you can be reasonably sure that the binary (or source) file being patched is the one you want. My suggestion would notify you that you've patched a backup version of the binary and that you would need to reapply your modification to the system. Normally this would be a two pass process, identifying the files to be updated and performing the update. During the identification phase, if a file has been found to be inconsistent and a user modification has been found in the database, then the modification can be identified, reported, and the user has the option of forcing the patch in, based on the original binary kept in backup, or aborting the patch. If the user forces the patch in, it would be up to the user to re-apply any user modifications. If on the other hand the user modification is not in the database, any user modification cannot be identified and the patch will need to be aborted. Then it's up to the user to figure out what went wrong. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message