On Thu, Apr 23, 2009 at 09:13:38AM +0000, "J.M.Roth" <lists+debianu...@roth.lu> was heard to say: > > >Oh and I guess to make things really right one would have to use > > >--get-selections '*' > > >during the backup, or an additional > > >dpkg --clear-selections > > >before the restore. Just a thought. > > > > --clear-selections before the restore makes sense. But, any selection > > other > > than "install" isn't really necessary to reproduce. > > If you consider a base system that you try to restore to some previously > existing system that you took the backup from, that may be true. But if you > want > to 'convert' a generic system to some other system (that you took the backup > from), it might be necessary to e.g. purge exim4 and install postfix, in case > the package management wouldn't figure that out on its own.
When I was working on this problem as a part-time sysadmin, I ended up writing a big "script" for aptitude. You can do this by (ab)using the ability to enter commands at the aptitude prompt. However, that doesn't give you the ability to "snapshot" a state easily, automatically and efficiently. Probably not the greatest idea. Another option you could take would be to generate a pkgstates file. You seem to be familiar with awk, so it shouldn't be hard. All you need is a bunch of stanzas like this, separated by blank lines: Package: cyrus-admin-2.3 State: 3 The "state" is a flag indicating the package's current state. It's written as an integer because I designed this code when I was young and foolish. :-) The relevant values are: 1 -> Install 2 -> Hold 3 -> Remove 4 -> Purge This is the file that "aptitude install" with no arguments uses to decide what to install. Generating it directly should give you a much simpler and faster script. Similarly, you should be able to generate /var/lib/apt/extended_states directly. Each stanza there looks like: Package: kpat Auto-Installed: 1 where of course "1" is "yes it is auto-installed". You can also have "0", but that means the same thing as not having a stanza at all for that package. Please note, I haven't tried any of this myself! And of course you'll be at the mercy of any future changes in file format (not that I know of any that are planned, and they'd have to be backwards-compatible anyway...) Daniel -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org