Annotation of wikisrc/projects/project/pkgsrc_undo.mdwn, revision 1.4
1.1 dholland 1: [[!template id=project
3: title="Undo support for pkgsrc"
13: If one embarks on a set of package updates and it doesn't work out too
14: well, it is nice to be able to roll back to a previous state.
15: This entails two things: first, reverting the set of installed
16: packages to what it was at some chosen prior time, and second,
17: reverting changes to configuration, saved application state, and other
18: such material that might be needed to restore to a fully working setup.
20: This project is about the first part, wihch is relatively tractable.
21: The second part is Hard(TM), but it's pointless to even speculate
22: about it until we can handle the first part, which we currently can't.
23: Also, in many cases the first part is perfectly sufficient to recover
24: from a problem.
26: Ultimately the goal would be to be able to do something like
27: pkgin --revert yesterday
28: but there are a number of intermediate steps to that to provide the
29: infrastructure; after that adding the support to pkgin (or whatever
30: else) should be straightforward.
1.2 dholland 32: The first thing we need is a machine-readable log somewhere of
1.1 dholland 33: package installs and deinstalls.
34: Any time a package is installed or removed, pkg_install adds a record
35: to this log.
36: It also has to be possible to trim the log so it doesn't grow without
37: bound -- it might be interesting to keep the full history of all
38: package manipulations over ten years, but for many people that's just
39: a waste of disk space.
40: Adding code to pkg_install to do this should be straightforward; the
41: chief issues are
1.4 ! dholland 42:
1.3 dholland 43: * choosing the format
44: * deciding where to keep the data
1.4 ! dholland 45:
1.1 dholland 46: both of which require some measure of community consensus.
48: Preferably, the file should be text-based so it can be manipulated by
49: hand if needed.
50: If not, there ought to be some way to recover it if it gets corrupted.
51: Either way the file format needs to be versioned and extensible to
52: allow for future changes.
54: The file format should probably have a way to enter snapshots of the
55: package state in addition to change records; otherwise computing the
56: state at a particular point requires scanning the entire file.
57: Note that this is very similar to deltas in version control systems
58: and there's a fair amount of prior art.
60: Note that we can already almost do this using
61: /var/backups/work/pkgs.current,v; but it only updates once a day and
62: the format has assorted drawbacks for automated use.
1.2 dholland 64: The next thing needed is a tool (maybe part of pkg_info, maybe not)
1.1 dholland 65: to read this log and both (a) report the installed package state as of
66: a particular point in time, and (b) print the differences between then
67: and now, or between then and some other point in time.
69: Given these two things it becomes possible to manually revert your
70: installed packages to an older state by replacing newer packages with
71: older packages.
72: There are then two further things to do:
1.2 dholland 74: Arrange a mechanism to keep the .tgz files for old packages on file.
1.1 dholland 75:
76: With packages one builds oneself, this can already be done by having
77: them accumulate in /usr/pkgsrc/packages; however, that has certain
78: disadvantages, most notably that old packages have to be pruned by
80: Also, for downloaded binary packages no comparable scheme exists yet.
1.2 dholland 82: Provide a way to compute the set of packages to alter, install, or
1.1 dholland 83: remove to switch to a different state.
84: This is somewhat different from, but very similar to, the update
85: computations that tools like pkgin and pkg_rolling-replace do, so it
86: probably makes sense to implement this in one or more of those tools
87: rather than in pkg_install; but perhaps not.
89: There are some remaining issues, some of which aren't easily solved
90: without strengthening other things in pkgsrc.
91: The most notable one is: what about package options? If I rebuild a
92: package with different options, it's still the "same" package (same
93: name, same version) and even if I record the options in the log,
94: there's no good way to distinguish the before and after binary packages.
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb