Date: Fri, 20 Mar 1998 13:04:45 -0500 (EST) From: "A. Karl Heller" <heller@cdnow.com> To: eivind@yes.no (Eivind Eklund) Cc: software@kew.com, stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <199803201804.NAA05038@daria.cdnow.com> In-Reply-To: <19980320104944.02752@follo.net> from "Eivind Eklund" at Mar 20, 98 10:49:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
I have to admit that the "patch" facility that Sun uses is rather nice. And I also agree that there are times that I wanted to fix bugs and upgrade certain sections of my system without pulling down the whole system and doing a make world. Don't get me wrong. Make world is a great feature for building an entire system. However, for those systems that are used in "production environments" this behavior is not very satisfying, even if only rebuilding a few apps. A binary patch would be very nice. ( On the flip side, I think Solaris has a lot more bugs than FreeBSD... But that could be only because I don't hear about the FreeBSD ones as much, or the fact that Solaris is running in many more environments.) In any case, some type of patch process would be very nice. I would suggest that it contain both source and binary patches. The installer would figure out if you actually have a source tree, etc.. Replacing the entire binary is probably the way to go. ( Except in cases of custom kernels, you would have to do a source rebuild. ) I'm still running 2.1.7.1 at home and our two FreeBSD boxes here are running 2.2-970801-RELENG. Once they are upgraded to 2.2.6 I probably won't source fix anything until 3.0 is official. I'm concerned about stability here. Karl > [Drew Derbyshire] > > I would suggest after the release a point release method be > > developed to allow (perhaps as a port type package?) The ability to > > download/apply critical fixes quickly. > > > > Simply put, having to track the entire -stable source to get > > bugfixes on the CD-ROM is not desirable. > Good suggestion! Go ahead and do it; I promise to post comments about > your design when you post it, and I'm sure Jordan and Mike will, too. > Quick requirements: > * Full authorization using public key cryptography > * It must be possible to back bad changes out. > * It must verify that the base-version it is upgrading from is correct > That's about it. You'll get extra points for: > * Automatic handling through e-mail > * Using the standard metadata format from the Java JAR files for > authentication > * Being able to apply binary diffs > * Writing this so the code can be re-used by the new package system > * Getting it done so it can ship with 2.2.6-RELEASE. (This gives LOTS > of points, and I'm sure there are several people that'll buy you a > beer for this. I'm one of them :-) > Eivind. > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message -- ----------------------------------------------------------------------------- A. Karl Heller | It is foolhardy to assume that jiggling X Senior Systems Engineer | will not diddle Y, however unlikely. CDnow Inc. | MSG FROM OPERATOR : http://cdnow.com | OUR HAMSTER IS SICK. SYSTEM SHUTDOWN IMMEDIATELY. 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?199803201804.NAA05038>