debuerreotype: Missing man directories in "slim" variants causes some packages to fail to install

Or

for i in $(seq 1 8); do mkdir -p "/usr/share/man/man${i}"; done

or

seq 1 8 | xargs -I{} mkdir -p /usr/share/man/man{}

, if {1..8} is not supported

For anyone else running into this, since the issue is just that the /usr/share/man{1-8} directories are missing, you can just create them and everything should work, as documented in many of the linked issues:

for i in {1..8}; do mkdir -p "/usr/share/man/man$i"; done

for i in {1..8}; do mkdir -p "/usr/share/man/man$1"; done

Typo: The variable should be $i, not $1.

for i in {1..8}; do mkdir -p "/usr/share/man/man$i"; done

FYI, this fix is included in https://github.com/docker-library/official-images/pull/10730. 😄

Happy Debian Day! 🎉

Typo: The variable should be $i, not $1

🤦‍♂️ Yes, sorry.

Well… You can’t remove random bits from a package and still call it installed, can you?

Back in 2001, there was an effort to move all doc from “/usr/doc” to “/usr/share/doc”. The -devel list have some debate on this. That migration took a policy change and two release to finish, because they decided all files in required packages are required.

For small distro like this, it is unavoidable to remove some files. When packages break because of this, either push for a policy change or just put the empty directory back .

To add a little extra information from some re-testing today, this command errors out in both jessie and stretch, but not in unstable, so the bit of code in update-alternatives which currently causes the failure in stable and oldstable is fixed in unstable. 🎉

I’ve merged a workaround for this in https://github.com/debuerreotype/debuerreotype/pull/116 which I don’t love, but will live with. Barring any major issues, it’ll be part of the next rebuild of the images.

Edit: to be clear: I’m still of the opinion that this is a bug in update-alternatives, but I think the chances of actually fixing it there are low (hence the workaround in debuerreotype-slimify instead).

Is there any agreement on the right long term fix for this issue ? I’ve just hit it with openjdk-11-jre-headless in both debian:10-slim and debian:sid-slim containers and its frustrating for users of the containers to have to add special case workarounds prior to installing certain packages.

Should the /usr/share/man/man* directory layout be preserved as empty dirs in the -slim images, or do the individual affected packages need to be identified and fixed to explicitly cope with missing man page directories ?

I could reproduce it with:

docker pull debian:unstable-slim
docker run -it debian:unstable-slim
apt update
apt install openjdk-11-jre-headless

To add a little extra information from some re-testing today, this command errors out in both jessie and stretch, but not in unstable, so the bit of code in update-alternatives which currently causes the failure in stable and oldstable is fixed in unstable.

@tianon The installation of openjdk-11-jre-headless (one of the affected packages) still fails on debian:unstable-slim:

Setting up openjdk-11-jre-headless:amd64 (11.0.8+10-1) ...
update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/java to provide /usr/bin/java (java) in auto mode
update-alternatives: error: error creating symbolic link '/usr/share/man/man1/java.1.gz.dpkg-tmp': No such file or directory
dpkg: error processing package openjdk-11-jre-headless:amd64 (--configure):
 installed openjdk-11-jre-headless:amd64 package post-installation script subprocess returned error exit status 2

Is there something else that needs to be done to get the fixed version?

This has been discussed a bit, and left as a bit of an intentional wart so that you (as the user of the image) get to be aware that a package you’re trying to install might be leaving files in a directory which is supposed to be purged.

It comes up often enough that I’m starting to waver on that point, though. Perhaps the majority of packages are well-behaved?

This behavior of update-alternatives exploding is amusing however, because once the target directory exists, update-alternatives will no-op immediately since it recognizes that the source file doesn’t exist.