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

Re: Backup package and dpkg (was Re: dpkg-disappear-replace.txt)

Ian Jackson:
   So, we're trying to do an exact restore given the same .deb files.
   Are we also trying to allow people to do a less-than-exact restore
   given somewhat-different .deb files ?

Oh, I don't know -- I guess this would be a good thing to include as
an option for cases where the exact restore is not possible.  I seem
to recall David's todo list having something on it to this effect.

Raul Miller:
   > However, if we accept that the backup system is going to try and
   > do a real system restore by providing a superstructure over the
   > dpkg system, I think that constitutes a need for dpkg to track
   > and export package installation order.

Ian Jackson:
   Right.  This could be tricky, though: potentially it may be
   necessary to install first A version 1, then B, then A version 2,
   then C, or similarly horrible things, and it's not clear when you
   decide to throw out old data.

Really? Can you describe the circumstances where this could occur?

Ideally, the backup system should explicitly deal with whatever files
would be handled ambiguously by a single package installation.
However, this probably means dpkg should be capable of clearly
identifying the files (or absence of files) which would be handled
ambiguously.  Probably, dpkg should also acquire an interface for
putting things back the way they were.

[Aside: I wonder if the current dpkg is simple enough for me to
understand it well enough to write the documentation on what it
currently does?]

Raul Miller:
   > Also, as an aside, I don't think it's fair to rely on dpkg to
   > recover packages which aren't in a fully installed state -- so it
   > should be the responsibility of the backup system to (a) issue
   > big warnings if it's backing up a system with installed but
   > unconfigured packages, and (b) backup all files from such
   > packages by default.

Ian Jackson:
   If you backup all files from such packages by default, and fiddle
   the dpkg status database to match, all will be well (if the rest of
   the system is restored correctly too).

Yeah, this sounds good.  And, this probably means more interface
definition at some point...

At the moment, I think it would be Really Neat if the backup system
could implement the backups as specialized .deb files.  I think the
backup system would have to call dpkg-deb directly, and keep its own
status information in some other directory, maybe /var/log/backup/.
But to a large degree the logical data structure of the .deb files is
very much what you need in a backup.

Exceptions: The compression aspect should be optional.  And, dpkg-deb
would need a way of specifying the files to go into the package
individually rather than including all files under some top-level


Reply to: