Date: Fri, 20 Mar 1998 23:48:52 -0800 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: "Daniel O'Callaghan" <danny@panda.hilink.com.au> Cc: gkshenaut@ucdavis.edu, stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <199803210749.XAA15210@cwsys.cwsent.com> In-Reply-To: Your message of "Sat, 21 Mar 1998 09:42:16 %2B1100." <Pine.BSF.3.91.980321093437.300D-100000@panda.hilink.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> The pkg system can be used here. pkgs record their own installation
> event, they have pre and post installation scripts which can display docs
> etc.
>
> > The assumptions would be that (1) all of the patches would adhere
> > to certain semantic conventions; (2) each patch could assume that
> > assume that a specified set of earlier patches had been applied;
>
> Patches with dependencies could check for those.
A LOT of thought needs to be put into this. I've been thinking about
this off-and-on for over a year now.
If you want to use packages, the whole system needs to be managed using
packages, just like Solaris, RedHat, and MVS, to name 3, are managed.
Patch packages would need to support pre-requisites, co-requisites and
be able to superceed other packages; and don't forget a backout process.
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).
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.
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?
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?
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).
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?199803210749.XAA15210>