Bug#518975: myspell-en-us: Fails to purge.
On Wed, Mar 11, 2009 at 12:10:33AM +0100, Kurt Roeckx wrote:
> On Tue, Mar 10, 2009 at 11:33:59PM +0100, Rene Engelhard wrote:
> > Kurt Roeckx wrote:
> > > Policy is pretty clear on this. You can not rely on Depends being
> > > present during the purge phase.
> > But that call is in *remove*, not purge.
> See #504880
While I see a relevant thing in last mail from Ian Jackson, it seems to
be mostly for corner cases, not for a normal use of the tools like should
be in autobuilders.
On the dictionaries side we could check from postrm if the script is present
before trying to run it, just to be more graceful with the corner cases Ian
points out. As a matter of fact Ian's mail convinced me about that, but that
is now a wishlist in dictionaries-common and dictionaries policy, and not at
all a serious bug, current (buggy) policy text is honoured, and problem only
appears in corner cases.
However, I keep thinking there is something wrong with autobuilders. Looking
at the ia64 compiz build log, I see that packages are unpacked, and before
they are configured, there is an error in unpacking lm-sensors,
Unpacking lm-sensors (from .../lm-sensors_1%3a3.1.0-1_ia64.deb) ...
rmdir: failed to remove `/etc/blacklist.d/': No such file or directory
dpkg: error processing
subprocess pre-installation script returned error exit status 1
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)
Package installation failed
Trying to reinstall removed packages:
Trying to uninstall newly installed packages:
After that, packages are removed *in alphabetical order*, probably because
they were not previously configured (I did not test the removal with
deconfigured packages, so I did not noticed about this) and the
reported error is about myspell-en-us, and not about the real original
problem, lm-sensors (noticed that you also filed a bug report about that, so
this should no longer be a problem). Showing only the last error in the
final report instead of all problems found looks like a bug in the
Asking autobuilders to run dpkg --configure --pending before actually
removing packages should have also worked around this problem, making
removal work in the correct ordering.