Due to my job I “have to” use Debian based systems. It now happened that a package from a test repository was totally broken beyond repair:
Removing xyz ... dpkg: error processing xyz (--remove): subprocess post-removal script returned error exit status 10 Errors were encountered while processing: xyz E: Sub-process /usr/bin/dpkg returned an error code (1)
All workarounds with purge, remove-reinstreq, -P or force-all failed. In the end, this tip showed how to remove the package manually:
First, check all files with dpkg -L xyz. Remove them manually, and afterwards delete the file /var/lib/dpkg/info/xyz.postrm. Last but not least, launch
apt-get remove --purge xyz
Be aware that this method is pretty evil. If you don’t know why that method is evil, don’t use it!
/home/liquidat 
You can also do
echo ‘exit 0’ >/var/lib/dpkg/info/xyz.postrm
and then dpkg –purge should work
WTF, dpkg doesn’t have a –noscripts option for cases like this?! (That’s how you’d fix that problem in RPM.)
Purge is evil? My understanding is that it just also removes the configuration files. I would also advocate looking at the postrm script and hacking around whatever line is failing (use -D with dpkg to get additional debug info) rather than just removing the script as this could leave additional junk on your system.
Kevin, not sure about that, but I didn’t found a –noscript. I’m just getting used to apt-get/dpkg, and while it does basically the same it is definitely a totally different piece of software…
Anonymous: Not the purge is the evil part, but the entire method of removing a package that way.