On Tue, Apr 25, 2000 at 05:54:20PM +0200, Andrzej Bialecki wrote:
> On Tue, 25 Apr 2000, Paul Richards wrote:
> > branch. Most commercial users are not developers, and have no interest
> > in anything relating to development. Professional sysadmins are
> > conservative creatures, they expect professional quality code to play by
> > the rules of the industry and those rules are widely accepted as meaning
> > that stable branches do no undergo ABI changes. Such changes are
> > reserved for major upgrades because of the consequences and risks
> > involved.
> On a similar note: I think one of serious drawbacks of FreeBSD's model for
> updating and bugfixing the stable branch is 'make world'. It's very
> inefficient and cumbersome way to do this on production machines. STABLE
> is stable enough for us to be able to prepare binary patches, which can be
> applied to a system in some (known) version. Especially security fixes,
> which are usually limited to specific programs.
> With such system present I'd be completely satisfied (as a production
> manager, not as a developer) if I could start with, let's say,
> 3.4-RELEASE, and then apply binary patches one by one to track
> STABLE. Instead of putting the machine out-of-service for a couple of
> hours, it would be 10 minutes. Also, no need to keep the sources
> around. Of course, implementing such a system requires careful versioning
> of each file in the standard system, but I think it's possible - just
> having the MD5 checksums around, for each consecutive patch, should do for
> start.
Number 1 problem that I see here is the amount of resources it needs to
do this. It appears this is hardly the kind of work somebody would want to
volunteer for. Question: are MD5 checksums the same for each and every build
(assuming static sources obviously) or is there some timestamp (or something
like that) in the generated binary. If there is, one could only create
binary patches relative to a -release.
--
Wilko Bulte Powered by FreeBSD http://www.freebsd.org
http://www.tcja.nl
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
