Date: Mon, 23 Mar 1998 09:51:29 -0800 (PST) From: David Wolfskill <dhw@whistle.com> To: freebsd-stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <199803231751.JAA10716@pau-amma.whistle.com>
next in thread | raw e-mail | index | archive | help
>From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>
>Date: Fri, 20 Mar 1998 23:48:52 -0800
>A LOT of thought needs to be put into this.
Very true.
>Patch packages would need to support pre-requisites, co-requisites and
>be able to superceed other packages; and don't forget a backout process.
Agreed.
>A simpler approach would be to use Sun's approach which bundles related
>patches into jumbo patches (though I'm partial to IBM's approach).
I have slightly more experience (both in duration & depth) with the
approach IBM use{s,d} with MVS (either /XA or /ESA), and confess to
slightly more comfort with that (vs. Sun's approach).
>Either way you just can't jump into this. The first step would be to
>have the base O/S managed via packages. That would be big chunk of the
>work. Then there's designing a patch application (or borrowing one)
>and managing patch releases.
IBM even has a separate product (SPM/E) to do this... and it's a
non-trival resource consumer (read "hog").
>Other questions to be answered would be, what O/S changes would be good
>candidates for patches and what could wait for the next release? Who
>would make these decisions? Who would package the patches?
Well, these seem similar in scope & nature to the issues of deciding
when some source gets committed....
>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.
Ummm.... Not necessarily.
What we did (when I was an MVS systems programmer) was write USERMODs,
and add them to the SPM/E database. What this does (and may be what Cy
is referring to) is notify you if there's a conflict between the USERMOD
and a patch that needs to be applied.
With that knowledge, then, the maintainer would then:
* Go look up the docs to see what sort of change there is. Sometimes
the change doesn't really affect the operation of the USERMOD, and
it's safe to:
* Back out ("reject") the USERMOD.
* Install ("apply") the patch.
* (Possibly) modify the SMP/E packaging for the USERMOD so it will
install cleanly.
* Install ("apply") the USERMOD.
* Sometimes a patch really does change the interface that a USERMOD
uses, and in that case, it may be necessary to re-work the USERMOD
itself.
* Other times, the patch make the whole USERMOD in question either moot
or impossible... but at least SMP/E will be rather noisy & let you
know about it... so there's some hope you can find out about it
beforehand, and make a decision as to what you're going to do.
> 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?
The USERMOD approach has some very nice things -- not least of which was
the basic design (in MVS), such that if the system found the existence
of a load module with a specified name (in a certain restricted list of
system libraries, of course!), control would be passed to that module
with a documented parameter list, and the module could do certain things
-- typically involving returning one of several return codes (to
indicate that the operation should continue as if the module had not
been called, should be rejected with a whimper, should be re-tried, or
aborted). The basic idea is that one makes a clean separation between
local code vs. "vendor" code.
>I think a lot of thought and discussion needs to be put into this
>before we decide if this should be done or when, should it be decided
>that we do it, what it should look like and whether the community is
>willing to commit using such a tool (there's no sense doing it if no
>one will be willing to follow the regimen).
There was, in the MVS world, a significant degree of resistance to the
use of SMP/E for packaging USERMODs... especially because of a lack of
discipline.
And it's rather like using RCS: it works well, as long as everyone
"plays by the ruules" -- but when somone goes in as root, modifies a
file, tries to write it, is told it's a read-only file, and thinks "What
do you mean, 'read-only': I'm root, I can change anything!" and writes
the change anyway... well, things tend to go downhill....
>Date: Mon, 23 Mar 1998 11:31:08 +1030
>From: "Daniel O'Connor" <doconnor@gsoft.com.au>
>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 where careful "packaging" of USERMODs comes in: defining *all*
of the pre-requisites & co-requisites.
>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.
Yes, I think so....
>Date: Sun, 22 Mar 1998 22:57:12 -0800
>From: Greg Shenaut <greg@bogslab.ucdavis.edu>
>I think patches are very different from packages. Packages are
>optional modules which can be added to a system; patches fix bugs
>in the system.
I'm comfortable with that terminology, and think that the distinction is
useful & valuable.
>Packages are distributed with the CD-ROM; it would
>make no sense for a patch to be distributed with a CD-ROM.
I wouldn't go quite that far, though I'd freely admit that it would make
more sense to have the content of the CD be fairly fixed, and have a
much more dynamic set of patches (and a somewhat less dynamic list of
which patches to apply to the CD to get a stable, working system).
Cheers,
david
--
David Wolfskill dhw@whistle.com (650) 577-7158 pager: (650) 401-0168
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?199803231751.JAA10716>