Backup package and dpkg (was Re: dpkg-disappear-replace.txt)
Raul Miller writes ("dpkg-disappear-replace.txt"):
> David's idea of using the dpkg status files to aid in backups got me
> to thinking: There's this feature of dpkg where older packages can be
> partially superceeded by newer packages, but I don't think dpkg
> currently tracks which package has superceeded which.
It does, in a way: when packages overwrite each others files in this
way it records the fact that the old package no longer contains the
file. However, it doesn't remember that this has happened.
> If I understand correctly, there's an order imposed on package
> installation by this feature. To use dpkg installation to recover a
> system, there would need to be some record of this order.
Indeed.
However, I don't think this is a problem. The feature's intended use
is to allow various kinds of upgrade to happen, not as a way of
deciding which packages provide certain files.
It is only intended to come into play when an older package is
superseded by one or more newer ones, and so it will be obvious what
the ordering is - in fact, it will be impossible to install the
packages in the wrong order because the old package won't exist any
more.
This shows a specific manifestation of a more general problem. In the
TODO we see:
] Backup should restore systems with the same versions of the Debian packages.
]
] If identical versions are not available, later ones could be used, but user
] must be warned.
]
] If backup restores a system (using old versions of packages) it should produce
] a report which identified the available newer packages.
This is not, in general, possible, because the archive site only
contains the most recent version of each package. However, I don't
think the warning is that necessary - it could be fairly obtrusive.
Here is why I think this:
A backup/restore using this technique will end up being essentially
equivalent to a simultaneous system upgrade of every package.
Bearing this in mind, it is reasonable to install different versions
of packages, or indeed different packages altogether.
What the restore program should do is to restore the `desired' states
for the available packages, and try to do something sensible for the
`undesired' ones.
We can then perhaps have the restore program either fudge the dpkg
database's idea of the conffiles state for the packages we're
installing, or go behind dpkg's back and do its own version of the
conffiles upgrade routine.
> Unfortunately, I don't have access to my debian systems at the
> moment, so I have to ask: is this feature present in the existing dpkg
> implementation?
Which feature ? The partial-overwriting/superseding ? Yes.
Recording of installation order and overwrites ? No.
Ian.
Reply to: