Date: Sun, 8 Dec 1996 14:11:58 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: last in -current Message-ID: <199612081311.OAA23270@uriah.heep.sax.de> In-Reply-To: <1075.850034047@time.cdrom.com> from "Jordan K. Hubbard" at "Dec 8, 96 00:34:07 am"
next in thread | previous in thread | raw e-mail | index | archive | help
As Jordan K. Hubbard wrote: > Well, like I said before, I think that a general "delta" system needs > to be evolved along these lines: I basically like that idea. Do you already have a more detailed imagination of the delta format (type field etc.)? > 1. All deltas have a consistent data format, sequence > numbered, uuencoded, PGP signed and for the benefit of the > migration tools (and easy sending through email). Hmmpf. Kill your government first. As long as we cannot provide PGP as a binary drop-in, this is a moot point. I see your point, but i'm afraid that all we could do by now is MD5-checking the deltas. > 3. Any time a delta procedure changes something, it or the migration > tools (for simpler deltas which have built-in handlers) will have > to register a "reverse delta", essentially a delta who's job it is > to go back to the previous state of affairs. I'm not yet convinced that this is always possible. Consider the wtmp changes. The best you could probably do is keeping the previous wtmp & Co files around in the reverse delta, but all system activity records between the upgrade and the application of the reverse delta will be lost upon applying the latter. And, the reverse delta may become _really huge_, so the upgrade procedure must offer several opportunities, like allowing to delete the latest reverse delta from the hard disk, storing the reverse delta on external media (tape, ZIP drive) without consuming much temp disk space, or even not generating the reverse delta at all for those who think they aren't interested in it. > ..., and I'm simply trying to suggest implementing a > framework somewhat more flexible than what we need for just this > one-time problem since it's be nice to actually implement a solution > which goes farther than just a one release, throw-away for a > change. :-) Yep. Now, who's going to become FreeBSD's ``upgrade meister''? Yet another vacant job position... :-) Wasn't there anybody asking for things to do recently??? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612081311.OAA23270>