*BSD News Article 44327


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!violet.berkeley.edu!jkh
From: jkh@violet.berkeley.edu (Jordan K. Hubbard)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: update to a snap
Date: 21 May 1995 08:56:04 GMT
Organization: University of California, Berkeley
Lines: 38
Message-ID: <3pmv74$2ll@agate.berkeley.edu>
References: <801015476k70585&1147298525r114@zurich.gcomm.com>
NNTP-Posting-Host: violet.berkeley.edu

In article <801015476k70585&1147298525r114@zurich.gcomm.com>,
CaptBly <captbly@zurich.gcomm.com> wrote:
>how do you update FreeBSD to one of the newer snaps without loosing
>everything??

At this time, you don't.  You back up any data you'd like to save and
you load the snap from scratch.

Now before everyone here screams "But that's utterly BOGUS!!" let me
just clarify what the snaps are for!  The snaps are not meant to be
release-substitutes, though many people use them that way, they're
meant to be test releases.  For them to be effective test releases,
I need to be able to roll them quickly and with a minimum of impact
on our mainstream development efforts.  I'd love to make the upgrade
process work, but it's a piece of technology that's hard to get right
and not one among FreeBSD's many thousands of users have stepped forward
with a proposed solution.  Since we rely on such donations of effort to
move forward (we are but a few at the core), it simply hasn't happened yet.

Now WRT upgrades between major releases, that's a slightly differerent matter
and one I will do my best to address.  It's a non-trivial problem, especially
when you are adding optimizations to the filesystem code that really _wants_
the user to remake all their filesystems to gain its full benefit (or have
completely gone from 32bit to 64bit offsets, as was the case in 1.1 -> 2.0).

In the long term, I'd like to be able to codify all the changes between
any point release and the next by expressing the changes as "deltas"
which could reside in a known location.  To upgrade from 2.1 to 2.2.4, the
installation mechanism would detect your current release and apply all
the intervening deltas.

I'd also like the several weeks worth of time this would take to
write.. :-)  If anyone out there desires to implement such a framework,
I would certainly do the release-specific work involved in using it.
It should be able to deal with removals, renames, adds and patches.

						Jordan