On Sat, 2005-02-19 at 20:46 +0100, Kurt Roeckx wrote: >It seems dpkg sets the state of a package wrong when the purge >failed and it was called with --purge. > Yup, verified with a banana ...
The (grossly oversimplified) steps that dpkg goes through are:
1) deferred_remove() is called on the package
2) package is placed in half-configured state
3) prerm script is called
4) package is placed in unpacked state
5) removal_bulk() is called
6) removal_bulk_remove_files() is called on the package
7) package is placed in half-installed state
8) package contents are removed
9) postrm script is called with remove argument
10) package info (except postrm and list files) is removed
11) package is placed in config-files state
12) removal_bulk_remove_configfiles() is called on the package
13) package config files are removed
14) postrm script is called with purge argument
15) removal_bulk_remove_remove_leftover_dirs() is called on the
package
16) package info (postrm and list files) is removed
17) package is placed in not-installed state
When the postrm/purge script fails, the package should be left in
config-file state, however for some reason it's being wound all the way
to installed.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
