So it looks to me like dpkg sometimes has troubles to replace the old directory with a file?
I tried this upgrade in a precise and quantal schroot (one using overlayfs, the other isn't, it's a tarball schroot) as well as just with espeak-data quantal → trusty upgrade on my production system, and on a precise live image. I also tried that upgrade with the old and new dpkg. In no case I could reproduce this bug.
As a workaround we might add a preinst script which just rm -r's /usr/lib/x86_64-linux-gnu/espeak-data/voices before the upgrade, but that would actually be wrong in the case that the upgrade fails, and it would not explain why that bug happens in the first place.
In the old version, voices/en/ is a directory:
/usr/ lib/x86_ 64-linux- gnu/espeak- data/voices/ en/ lib/x86_ 64-linux- gnu/espeak- data/voices/ en/en lib/x86_ 64-linux- gnu/espeak- data/voices/ en/en-us
/usr/
/usr/
(containing "en", "en-us", etc.), while in the new version it is a plain file:
/usr/ lib/x86_ 64-linux- gnu/espeak- data/voices/ en lib/x86_ 64-linux- gnu/espeak- data/voices/ en-us
/usr/
So it looks to me like dpkg sometimes has troubles to replace the old directory with a file?
I tried this upgrade in a precise and quantal schroot (one using overlayfs, the other isn't, it's a tarball schroot) as well as just with espeak-data quantal → trusty upgrade on my production system, and on a precise live image. I also tried that upgrade with the old and new dpkg. In no case I could reproduce this bug.
As a workaround we might add a preinst script which just rm -r's /usr/lib/ x86_64- linux-gnu/ espeak- data/voices before the upgrade, but that would actually be wrong in the case that the upgrade fails, and it would not explain why that bug happens in the first place.