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