Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Mar 1998 09:42:16 +1100 (EST)
From:      "Daniel O'Callaghan" <danny@panda.hilink.com.au>
To:        gkshenaut@ucdavis.edu
Cc:        stable@FreeBSD.ORG
Subject:   Re: after the release ... 
Message-ID:  <Pine.BSF.3.91.980321093437.300D-100000@panda.hilink.com.au>
In-Reply-To: <199803201901.LAA03383@myrtle1.bogs.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 20 Mar 1998, Greg Shenaut wrote:

> 
> Has anyone seen the BSDI approach to post-release patches? Once a
> problem has been fixed, the code to fix it is rolled up into an
> executable file, generally a perl script, which contains a brief
>.....
> carefully targeted, stand-alone, ASCII, self-documenting files
> which can be used to fix bugs in a released system.  They are not
> used for enhancements or other "upgrade"-like system modifications.

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.

> (3) all patches are relative to a specific (i.e., the most recent
> previous) RELEASE version (so that they are relative to a fixed,
> not a moving, target).  All patches would be ASCII, but the particular

Since pkg_add will handle URLs for .tgz files, and *most* FreeBSD systems
which would be upgraded like this have some relationship to the Internet,
even if it is only by sneakernet, I think pkg format is appropriate.

> Who would develop the patches?  I would say that given a reasonably
> well-defined set of conventions, the developer should be able to
> create a patch corresponding to whatever changes he or she developed
> with very little extra work.

So what we want is a Makefile which will make an update patch, so the 
committer can create this new patch.  We might end up with a lot of 
these, though. Perhaps it would be better to have a patchmeister (did I 
hear you volunteer, Drew? :-)) who could collect the patch-package 
creation requests and release an upgrade package every so often.
 
> What about security?  This is an *excellent* point.  It's a bit risky
PGP signature.

/*  Daniel O'Callaghan                                                     */
/*  HiLink Internet <http://www.hilink.com.au/>;       danny@hilink.com.au  */
/*  FreeBSD - works hard, plays hard...                 danny@freebsd.org  */



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.91.980321093437.300D-100000>