Date: Mon, 23 Mar 1998 11:41:25 -0800 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>, "Daniel O'Callaghan" <danny@panda.hilink.com.au>, gkshenaut@ucdavis.edu, stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <199803231942.LAA07832@passer.osg.gov.bc.ca> In-Reply-To: Your message of "Mon, 23 Mar 1998 11:31:08 %2B1030." <199803230101.LAA28437@cain.gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803231942.LAA07832>