Date: Sun, 08 Dec 1996 00:34:07 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@freebsd.org (FreeBSD-current users) Subject: Re: last in -current Message-ID: <1075.850034047@time.cdrom.com> In-Reply-To: Your message of "Sat, 07 Dec 1996 22:34:36 %2B0100." <199612072134.WAA23001@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> I think we're more headed towards a migration tool. My system ain't > fully -current again, once it is, i'm in an urgent need to write the > tool. If possible at all, i'll try to write it with some heuristics > so it can also migrate wtmp's that have trailing records written using > the new scheme. Well, like I said before, I think that a general "delta" system needs to be evolved along these lines: 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). 2. Based on its type field, which would be extensible, the migration tools will know what to do with a delta once it's been decoded, verified and checked for applicability. A delta could be as simple as a unidiff for patch, it could be a perl script or other executable which is run to perform some more complex action. 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. This means that a side-effect of applying a bunch of deltas to your system is the creation of *another* set of deltas under a common collection name (say "undo"). You could then go ask to apply the undo collection later if you wanted to undo the previous action, bringing you back to your pre-upgrade state. The migration tools should also have the concept of "destructive delta application", where deltas of that class don't cause a reverse-op to happen and are themselves deleted upon being applied, giving you one level of undo. All that was probably a lot more complex to describe than it might be to actually do. :-) Once you've done that, the creation of a "wtmp migrator" becomes pretty easy. I don't mean to come down on Joerg with a huge spec here in response to a small problem, but a haphazard collection of upgrade bits is what we have *already*, 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. :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1075.850034047>