Annotation of wikisrc/projects/project/pkgsrc_undo.mdwn, revision 1.3

1.1       dholland    1: [[!template id=project
                      3: title="Undo support for pkgsrc"
                      5: contact="""
                      6: [tech-pkg](
                      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.
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.3     ! dholland   42: * choosing the format
        !            43: * deciding where to keep the data
1.1       dholland   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.
1.2       dholland   62: The next thing needed is a tool (maybe part of pkg_info, maybe not)
1.1       dholland   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:
1.2       dholland   72: Arrange a mechanism to keep the .tgz files for old packages on file.
1.1       dholland   73: 
                     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.
1.2       dholland   80: Provide a way to compute the set of packages to alter, install, or
1.1       dholland   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 <> software: FreeBSD-CVSweb