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

Bug #703230 reported by Michael Bienia on 2011-01-15
40
This bug affects 4 people
Affects Status Importance Assigned to Milestone
pango1.0 (Debian)
Fix Released
Unknown
pango1.0 (Ubuntu)
High
Michael Vogt
Natty
High
Michael Vogt

Bug Description

When trying to update my natty system today, I got the following error when updating libpango1.0-0:

(Reading database ... 143454 files and directories currently installed.)
Preparing to replace libpango1.0-0 1.28.3-3 (using .../libpango1.0-0_1.28.3-4_amd64.deb) ...
rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
dpkg: error processing /var/cache/apt/archives/libpango1.0-0_1.28.3-4_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libpango1.0-0_1.28.3-4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

$ ls -ld /usr/share/doc/libpango1.0-0/
drwxr-xr-x 2 root root 4096 2007-07-31 20:23 /usr/share/doc/libpango1.0-0/

Perhaps some leftover from the past as this system was installed some years ago and followed most of the time the current development release.

Related branches

Daniel Hahler (blueyed) on 2011-02-14
Changed in pango1.0 (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Daniel Hahler (blueyed) wrote :

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.

Changed in pango1.0 (Ubuntu):
assignee: nobody → Daniel Hahler (blueyed)
status: Triaged → In Progress
Daniel Hahler (blueyed) wrote :

@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.

Changed in pango1.0 (Ubuntu):
status: In Progress → Triaged
assignee: Daniel Hahler (blueyed) → nobody
Jean-Baptiste Lallement (jibel) wrote :

Reproduced during an upgrade from maverick.

Changed in pango1.0 (Ubuntu Natty):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Jean-Baptiste Lallement (jibel) wrote :

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

Changed in pango1.0 (Ubuntu Natty):
assignee: Canonical Desktop Team (canonical-desktop-team) → nobody
importance: Medium → High
Martin Pitt (pitti) on 2011-03-15
Changed in pango1.0 (Ubuntu Natty):
assignee: nobody → Sebastien Bacher (seb128)
Sebastien Bacher (seb128) wrote :

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

Changed in pango1.0 (Debian):
status: Unknown → Fix Released
Michael Vogt (mvo) wrote :

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.

Changed in pango1.0 (Ubuntu Natty):
status: Triaged → Fix Committed
Sebastien Bacher (seb128) wrote :

thanks mvo!

Changed in pango1.0 (Ubuntu Natty):
assignee: Sebastien Bacher (seb128) → Michael Vogt (mvo)
Launchpad Janitor (janitor) wrote :

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

Changed in pango1.0 (Ubuntu Natty):
status: Fix Committed → Fix Released
Michael Bienia (geser) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.