Skip site navigation (1)Skip section navigation (2)
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>