Date: Mon, 23 Mar 1998 15:52:03 -0500 (EST) From: Derek Flowers <djflow@portwwwbus.tc.cc.va.us> To: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> Cc: "Daniel O'Connor" <doconnor@gsoft.com.au>, "Daniel O'Callaghan" <danny@panda.hilink.com.au>, gkshenaut@ucdavis.edu, stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <Pine.BSF.3.96.980323154739.13675B-100000@portwwwbus.tc.cc.va.us> In-Reply-To: <199803231500.HAA10455@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Mar 1998, Cy Schubert - ITSD Open Systems Group wrote: > > > > > 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.. > > That's right! That's why a philosophy should be chosen and strictly > adhered to. Every sysadmin would need to follow this or he/she would > have a mess, e.g. patches would not install if the state was not > consistent with what was expected, and a reinstall would be required to > get back to a know state. > > > > > 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. > > That's where the USERMOD would be used. The individual sysadmin would > need to tell the system by using a packaged application to modify the > system. This way the system would know why any particular binary (or > source module) would be inconsistent with expectations. (The USERMOD > process would allow modifications but make backup copies of "vendor" > supplied binaries and sources in the process.) If a USERMOD was > detected, the backup copy would be used and the USERMOD would be > verbosely deleted. The sysadmin would need to re-apply their > customization. > > I'm not saying that we need to adopt IBM's approach. We just need to > consider _all_ of the ramifications and do it right. > > > 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 The best way to go on custom changes is that the patch checks the md5 checksum of the file it is going to replace and if it does not match, abort the installation. It seems to me that someone doing custom work on files should have the sources and the time to patch stuff manually. A binary patch system is mainly for those who do not have the space or the time to install the sources, make the changes, recompile, and reinstall. ---------------------------------------- Derek Flowers djflow@erols.com http://portwwwbus.tc.cc.va.us/~djflow "640K ought to be enough for anybody." -Bill Gates, circa 1981 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?Pine.BSF.3.96.980323154739.13675B-100000>