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