"rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory" when updating to 1.28.3-4

In my case the directory was empty, and "rmdir" instead of "rm -f" would have fixed it.

It is more likely that "rm -rf" was meant to be used here.

I will investigate if I can find a reference to some bug about this and provide a proper fix for this here.

@pochu: you appear to have added this for 1.28.3-4 in Debian experimental.
Please look into fixing this, possibly by using "rmdir", if you're expecting it to be an empty directory - but then with "|| true" maybe so that it does not break installation in case if the directory is non-empty because of custom files.

Reproduced during an upgrade from maverick.

increasing importance to high because it completely breaks the upgrade, leaving the system in a non working state (and recovering manually is non trivial)

Debian has http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616577 about that issue, I've added a comment there

I upoaded a simple fix for this now. I'm not sure how the system got into the situation that resulted in a dir instead of a symlink though. But even then, it should not fail.

thanks mvo!

This bug was fixed in the package pango1.0 - 1.28.3-4ubuntu3

---------------
pango1.0 (1.28.3-4ubuntu3) natty; urgency=low

  * debian/libpango1.0-0.preinst:
    - check for symlink target before calling rm (LP: #703230)
      This fixes a upgrade bug, thanks to Alexander Kurtz for
      this patch
 -- Michael Vogt <email address hidden> Fri, 25 Mar 2011 16:41:15 +0100

My guess is that it happened in the past when the package switched from directory to that symlink (between dapper and hardy somewhen) that it didn't get handled properly ("A directory will never be replaced by a symbolic link to a directory or vice versa" (Debian policy §6.6.4)). But as this didn't cause any problems till now it went unnoticed. So only system which got installed a couple releases ago and got upgraded constantly should be affected.