Bug#986165: libcupsimage2: Upgrade fails with `m: cannot remove '/usr/share/doc/libcupsimage2': Directory not empty`

[Didier 'OdyX' Raboud <odyx@debian.org>]

Control: tags -1 +pending

Dear Paul,

Le mardi, 30 mars 2021, 19.11:07 h CEST Paul Menzel a écrit :
> In a Debian 10 (buster) Docker container upgrading the package
> *libcupsimage2* fails with the error below.

Thanks for your bugreport.

> ```
> # apt full-upgrade
> […]
> Preparing to unpack .../066-libcupsimage2_2.2.10-6+deb10u4_amd64.deb ...
> rm: cannot remove '/usr/share/doc/libcupsimage2': Directory not empty
> dpkg: error processing archive
> /tmp/apt-dpkg-install-XQ7mPL/066-libcupsimage2_2.2.10-6+deb10u4_amd64.deb
> (--unpack):
>   new libcupsimage2:amd64 package pre-installation script subprocess
> returned error exit status 1
> Preparing to unpack .../067-libavahi-common-data_0.7-4+deb10u1_amd64.deb ...
> […]
> # ls /usr/share/doc/libcupsimage2
> changelog.Debian.gz  changelog.gz  copyright
> ```

This seems to be because Debian Docker images setup dpkg to not unpack files 
in /usr/share/doc, but the various debian preinsts try to remove that 
directory before installation. The current CUPS' libcupsimage2 preinst has the 
following lines:

case "$1" in
    upgrade)
        if [ ! -L /usr/share/doc/libcupsimage2 ]; then
            rm -rf /usr/share/doc/libcupsimage2
        fi
    ;;

… These are the ones that fail.

But they have been in CUPS' maintscripts since at least 2005, and I don't see 
their point. If they were ever useful, there have been so many stable releases 
since…

I'll remove these snippets and upload to experimental.

Best regards,

    OdyX

Attachment: signature.asc
Description: This is a digitally signed message part.