Bug#986165: libcupsimage2: Upgrade fails with `m: cannot remove '/usr/share/doc/libcupsimage2': Directory not empty`
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/
01autoremove70debconf 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
Bug#986165: libcupsimage2: Upgrade fails with `m: cannot remove '/usr/share/doc/libcupsimage2': Directory not empty`
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 signature.asc Description: This is a digitally signed message part.
Bug#986165: libcupsimage2: Upgrade fails with `m: cannot remove '/usr/share/doc/libcupsimage2': Directory not empty`
Package: libcupsimage2 Version: 2.2.10-6+deb10u4 Severity: normal Dear Debian folks, In a Debian 10 (buster) Docker container upgrading the package *libcupsimage2* fails with the error below. ``` # 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 ``` I found one forum post from 2015 with the same error on Linux Mint upgrading *libcupsimage2:amd64* from 1.7.2-0ubuntu1.5 to 1.7.2-0ubuntu1.6. [1] System information: ``` # more /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/; SUPPORT_URL="https://www.debian.org/support; BUG_REPORT_URL="https://bugs.debian.org/; # dpkg -l libcupsimage2 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---== ii libcupsimage2:amd64 2.2.10-6+deb10u2 amd64Common UNIX Printing System(tm) - Raster image library # apt-cache policy libcupsimage2 libcupsimage2: Installed: 2.2.10-6+deb10u2 Candidate: 2.2.10-6+deb10u4 Version table: 2.2.10-6+deb10u4 500 500 http://deb.debian.org/debian buster/main amd64 Packages *** 2.2.10-6+deb10u2 100 100 /var/lib/dpkg/status ``` Kind regards, Paul [1]: https://forums.linuxmint.com/viewtopic.php?t=201930
