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
