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

[Paul Menzel <pmenzel@molgen.mpg.de>]

Dear Didier,


Am 30.03.21 um 19:59 schrieb Didier 'OdyX' Raboud:
> Control: tags -1 +pending

> 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 as shown above, there are three files in the `/u/s/doc/` directory.

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

Hmm, the force switch in `rm -rf` shouldn’t fail, shouldn’t it? But 
indeed, that is the line present:

    # grep rm /var/lib/dpkg/info/libcupsimage2\:amd64.*
    /var/lib/dpkg/info/libcupsimage2:amd64.preinst:     rm -rf 
/usr/share/doc/libcupsimage2


```
# ls /etc/apt/apt.conf.d/
01autoremove                70debconf                   docker-clean 
            docker-no-languages
50apt-file.conf             docker-autoremove-suggests 
docker-gzip-indexes
root@25f728ea4959:/# more /etc/apt/apt.conf.d/docker-clean
# Since for most Docker users, package installs happen in "docker build" 
steps,
# they essentially become individual layers due to the way Docker handles
# layering, especially using CoW filesystems.  What this means for us is 
that
# the caches that APT keeps end up just wasting space in those layers, 
making
# our layers unnecessarily large (especially since we'll normally never use
# these caches again and will instead just "docker build" again and make 
a brand
# new image).

# Ideally, these would just be invoking "apt-get clean", but in our testing,
# that ended up being cyclic and we got stuck on APT's lock, so we get 
this fun
# creation that's essentially just "apt-get clean".
DPkg::Post-Invoke { "rm -f /var/cache/apt/archives/*.deb 
/var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true"; };
APT::Update::Post-Invoke { "rm -f /var/cache/apt/archives/*.deb 
/var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true"; };

Dir::Cache::pkgcache "";
Dir::Cache::srcpkgcache "";

# Note that we do realize this isn't the ideal way to do this, and are 
always
# open to better suggestions 
(https://github.com/debuerreotype/debuerreotype/issues).
```

> 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.
Sounds good.


Kind regards,

Paul