[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question about get-selections



On 2009-04-23_21:27:07, Daniel Burrows wrote:
> On Thu, Apr 23, 2009 at 09:13:38AM +0000, "J.M.Roth" <lists+debianuser@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

Besides get-selections there are other approaches to saving and restoring
the state of the apt system. Are you aware of the documentation package
for aptitude? It is available the many languages as html files in debian
packages all ending with a spcific language code. In that package, in the
English version anyway, there is documentation of two relevant programs:
aptitude-create-state-bundle and
aptitude-run-state-bundle

The first bundles up what is claimed to be everything that is needed to recreate
the current state of the local apt system. The second unbundles the bundly and
puts it where it belongs in order to be fully functional.

In the aptitude-create-state-bundle description, they give a list of exactly
what they (the documenters of the aptitude program no less) believe to be
the sum total of what is needed to recreate a living apt system. This list is:

    $HOME/.aptitude
    /var/lib/aptitude
    /var/lib/apt
    /var/cache/apt/*.bin
    /etc/apt
    /var/lib/dpkg/status

It is not a very long list, but it does include a lot more than merely
a list of installed packages, and, particularly significant for this
thread, it does not include a copy of the output from running
--get-selections.

I think persons who are conserned about how best to use
--get-selections output might well study the aptitude document in
greater detail than I have.

What I have done for my systems is to include these files/directories
in my nightly backup of each of my systems. I've sort of subsumed the
meat of their idea into a larger backup system. I haven't tested
rebuilding a system that crashed and burned form by nightly backups,
but I'm sure that I'll be better off with these files than without
them if I ever have to rebuild from scratch.

HTH
-- 
Paul E Condon           
pecondon@mesanetworks.net


Reply to: