Re: Backup package and dpkg (was Re: dpkg-disappear-replace.txt)
rdm@tad.micro.umn.edu:
> Hmm... I agree that this feature's intended use was to allow certain
> kinds of upgrades to happen. However, I think I disagree with the
> rest of this stuff.
>
> [...]
> Now, obviously, it would be the responsibility of the backup system
> and backup administrator to track the storage of backup information --
> including where the proper .deb files are kept.
Ah, right. I see. 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 ?
> 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.
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.
> 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.
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).
Ian.
Reply to: