DietPi-Cleaner | Purging man pages can cause APT errors

[maartenlangeveld]

Details:

• Date | Wed 1 May 01:05:01 CEST 2019
• Bug report | N/A
• DietPi version | v6.22.3 (Fourdee/master)
• Img creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi Zero W (armv6l) (index=1)
• Kernel version | Request | RT Kernel option #1200 Tue Feb 12 20:11:02 GMT 2019
• Distro | stretch (index=4)
• Command | G_AGA
• Exit code | 100
• Software title | DietPi-Cleaner

Steps to reproduce:

1. commandline: "dietpi-cleaner 1"

Expected behaviour:

• dietpi-cleaner to run

Actual behaviour:

• dietpi-cleaner exits with error

Extra details:

Additional logs:

Log file contents:
Setting up openjdk-8-jre-headless:armhf (8u212-b01-1~deb9u1) ...
update-alternatives: warning: forcing reinstallation of alternative /usr/lib/jvm/java-8-openjdk-armhf/jre/bin/rmid because link group rmid is broken
update-alternatives: error: error creating symbolic link '/usr/share/man/man1/rmid.1.gz.dpkg-tmp': No such file or directory
dpkg: error processing package openjdk-8-jre-headless:armhf (--configure):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of openjdk-8-jdk-headless:armhf:
 openjdk-8-jdk-headless:armhf depends on openjdk-8-jre-headless (= 8u212-b01-1~deb9u1); however:
  Package openjdk-8-jre-headless:armhf is not configured yet.

dpkg: error processing package openjdk-8-jdk-headless:armhf (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 openjdk-8-jre-headless:armhf
 openjdk-8-jdk-headless:armhf
E: Sub-process /usr/bin/dpkg returned an error code (1)

[MichaIng]

@maartenlangeveld
Many thanks for your report.

Yeah some packages do not handle missing man pages gracefully. I actually only faced this on some Buster updates but was mostly resolved with another update.

Please try:

> /usr/share/man/man1/rmid.1.gz
apt -f install

[Fourdee]

Options:

• 0byte each file in /usr/share/man, however, leaves a vast number of files in place, 4K min each. No real benefit.

---

Solution:

• Added a confirmation prompt, before removal of manpages/docs:
  

[Fourdee]

@MichaIng

This should do for now, I believe the other option is to disable manpage/doc cleaning method?

[MichaIng]

@Fourdee
Jep. The cases this occurs are very rare anyway and I would consider this as external bug. Missing files on APT install/update should ALWAYS be handled gracefully, instead they should be simply skipped and/or re-created. The rare cases where I ran into this were on Buster and have all been fixed.

E.g. I go with this on my system:

cat << _EOF_ > /etc/dpkg/dpkg.cfg.d/01-micha
path-exclude /usr/share/doc/*
# We need to keep copyright files for legal reasons
path-include /usr/share/doc/*/copyright
path-exclude /usr/share/doc-base/*
path-exclude /usr/share/groff/*
path-exclude /usr/share/info/*
path-exclude /usr/share/linda/*
path-exclude /usr/share/lintian/*
path-exclude /usr/share/man/*
path-exclude /usr/local/man/*
path-exclude /usr/local/share/man/*
path-exclude /etc/alternatives/*.gz
path-exclude /var/lib/dpkg/alternatives/*.gz
_EOF_

• So those files are never installed by DPKG/APT.

As I like this to reduce overall disk I/O and space usage, I am thinking about a check for related file path in error output and in case automatically create the affected file + rerun APT. If I remember correctly the error message is always from similar scheme since it is a DPKG internal function to alter/handle these files. However let's stay with this for now.

[MichaIng]

Hehe just tested the above together with Buster software install tests and just ran into an example error:

Log file contents:
Setting up openjdk-11-jre-headless:amd64 (11.0.3+1-1) ...^M
update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/rmid to provide
/usr/bin/rmid (rmid) in auto mode^M
 update-alternatives: error: error creating symbolic link
'/usr/share/man/man1/rmid.1.gz.dpkg-tmp': No such file or directory^M
dpkg: error processing package openjdk-11-jre-headless:amd64 (--configure):^M

• Solution (simply on second SSH session, then hit "retry"): mkdir -p /usr/share/man/man1 && > /usr/share/man/man1/rmid.1.gz.dpkg-tmp

---

Next:

Setting up fahclient (7.5.1) ...
/var/lib/dpkg/info/fahclient.postinst: line 40: /usr/share/doc/fahclient/sample-config.xml: No such file or directory
dpkg: error processing package fahclient (--configure):
 installed fahclient package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 fahclient

• Okay but this one is expected. Actually /usr/share/doc it known to be used for example config/service/etc files. Switched to: path-exclude /usr/share/doc/*.gz

---

Positive example:

Setting up tigervnc-common (1.9.0+dfsg-3) ...
update-alternatives: using /usr/bin/tigervncconfig to provide /usr/bin/vncconfig (vncconfig) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/vncconfig.1.gz because associated file /usr/share/man/man1/tigervncconfig.1.gz (of link group vncconfig) doesn't exist
update-alternatives: using /usr/bin/tigervncpasswd to provide /usr/bin/vncpasswd (vncpasswd) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/vncpasswd.1.gz because associated file /usr/share/man/man1/tigervncpasswd.1.gz (of link group vncpasswd) doesn't exist
Setting up tcl8.6 (8.6.9+dfsg-2) ...
Setting up libtk8.6:amd64 (8.6.9-2) ...
Setting up tigervnc-standalone-server (1.9.0+dfsg-3) ...
update-alternatives: using /usr/bin/tigervncserver to provide /usr/bin/vncserver (vncserver) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/vncserver.1.gz because associated file /usr/share/man/man1/tigervncserver.1.gz (of link group vncserver) doesn't exist
update-alternatives: using /usr/bin/Xtigervnc to provide /usr/bin/Xvnc (Xvnc) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/Xvnc.1.gz because associated file /usr/share/man/man1/Xtigervnc.1.gz (of link group Xvnc) doesn't exist