Date: Fri, 20 Mar 1998 11:00:51 -0800 From: Greg Shenaut <greg@bogslab.ucdavis.edu> To: stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <199803201901.LAA03383@myrtle1.bogs.org> In-Reply-To: Your message of "Fri, 20 Mar 1998 08:54:40 PST." <Pine.BSF.3.96.980320084922.11627B-100000@coyote.prepaid.atlas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 description of what the patch does and what the possible operations which the script can perform (generally either examine the patches in some way, or to apply them). There is a kind of primitive logging so that the system knows which patches have been applied, and won't reapply them. The scripts are always ASCII, so they can be mailed or posted. In BSD/OS, they divide up the patches into kernel vs user, and source vs binary. To summarize, patches are 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. I think that for people who are constantly tracking each software change, or who heavily modify the distributed source, this system would be unworkable. But for perhaps the majority of users, who upgrade only to the CD-ROMs or the "RELEASE" distributions, I think that something similar to the BSDI scheme would be a very workable way to distribute post-release patches. 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; (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 format would be up to the developer of the patch: shell archives, perl scripts, whatever. But in every case, just typing "./PATCHNAME" should get the documentation on standard output. (In some cases, large patches might be compressed; in this case, the script should perform any needed decompression as well.) 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. How could the patches be gotten? Well, there should go on the "stable" mailing list, probably, and they could go on the "announce" newsgroup, as well as the usual web/ftp archives. What about security? This is an *excellent* point. It's a bit risky to be blindly applying emailed or posted patches to your system. I do not have a good answer to this--perhaps it is a strong argument against mailing or posting the patches; maybe they should only be downloaded directly from a central, secure site. Anyway, think this scheme would work well; it can be implemented noncentrally, by each developer, and it allows people to rely much more on the RELEASE versions, plus patches. -Greg 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?199803201901.LAA03383>