Annotation of wikisrc/projects/project/pkgsrc_undo.mdwn, revision 1.1
1.1 ! dholland 1: [[!template id=project
! 3: title="Undo support for pkgsrc"
! 5: contact="""
! 6: [tech-pkg](mailto:tech-pkg@NetBSD.org)
! 7: """
! 9: category="pkgsrc"
! 10: difficulty="medium"
! 12: description="""
! 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.
! 32: 1. The first thing we need is a machine-readable log somewhere of
! 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
! 42: * choosing the format
! 43: * deciding where to keep the data
! 44: both of which require some measure of community consensus.
! 46: Preferably, the file should be text-based so it can be manipulated by
! 47: hand if needed.
! 48: If not, there ought to be some way to recover it if it gets corrupted.
! 49: Either way the file format needs to be versioned and extensible to
! 50: allow for future changes.
! 52: The file format should probably have a way to enter snapshots of the
! 53: package state in addition to change records; otherwise computing the
! 54: state at a particular point requires scanning the entire file.
! 55: Note that this is very similar to deltas in version control systems
! 56: and there's a fair amount of prior art.
! 58: Note that we can already almost do this using
! 59: /var/backups/work/pkgs.current,v; but it only updates once a day and
! 60: the format has assorted drawbacks for automated use.
! 62: 2. The next thing needed is a tool (maybe part of pkg_info, maybe not)
! 63: to read this log and both (a) report the installed package state as of
! 64: a particular point in time, and (b) print the differences between then
! 65: and now, or between then and some other point in time.
! 67: Given these two things it becomes possible to manually revert your
! 68: installed packages to an older state by replacing newer packages with
! 69: older packages.
! 70: There are then two further things to do:
! 72: 3. Arrange a mechanism to keep the .tgz files for old packages on file.
! 74: With packages one builds oneself, this can already be done by having
! 75: them accumulate in /usr/pkgsrc/packages; however, that has certain
! 76: disadvantages, most notably that old packages have to be pruned by
! 77: hand.
! 78: Also, for downloaded binary packages no comparable scheme exists yet.
! 80: 4. Provide a way to compute the set of packages to alter, install, or
! 81: remove to switch to a different state.
! 82: This is somewhat different from, but very similar to, the update
! 83: computations that tools like pkgin and pkg_rolling-replace do, so it
! 84: probably makes sense to implement this in one or more of those tools
! 85: rather than in pkg_install; but perhaps not.
! 87: There are some remaining issues, some of which aren't easily solved
! 88: without strengthening other things in pkgsrc.
! 89: The most notable one is: what about package options? If I rebuild a
! 90: package with different options, it's still the "same" package (same
! 91: name, same version) and even if I record the options in the log,
! 92: there's no good way to distinguish the before and after binary packages.
! 94: """
! 95: ]]
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb