Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing man directories in "slim" variants causes some packages to fail to install #10

Open
mithrandi opened this issue Jun 13, 2017 · 12 comments

Comments

@mithrandi
Copy link

commented Jun 13, 2017

For example, postgresql-client-9.4 installs an alternative for psql.1 resulting in this failure to install (apt-get install postgresql-client in a debian:jessie-slim container):

Setting up postgresql-client-9.4 (9.4.12-0+deb8u1) ...                     
update-alternatives: using /usr/share/postgresql/9.4/man/man1/psql.1.gz to provide /usr/share/man/man1/psql.1.gz (psql.1.gz) in auto mode
update-alternatives: error: error creating symbolic link `/usr/share/man/man1/psql.1.gz.dpkg-tmp': No such file or directory
dpkg: error processing package postgresql-client-9.4 (--configure): 
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of postgresql-client:
 postgresql-client depends on postgresql-client-9.4; however:
  Package postgresql-client-9.4 is not configured yet. 
                                                                                                                                                           
dpkg: error processing package postgresql-client (--configure):       
 dependency problems - leaving unconfigured

Leaving the empty directories behind should be enough to fix this, I think.

@mithrandi mithrandi changed the title Missing man directories causes some packages to fail to install Missing man directories in "slim" variants causes some packages to fail to install Jun 13, 2017

@tianon

This comment has been minimized.

Copy link
Collaborator

commented Jun 13, 2017

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.

@eigood

This comment has been minimized.

Copy link

commented Aug 9, 2017

FROM debian:stretch works, FROM debian:stretch-slim does not, with no other changes. Makes me lean towards the -slim tooling being broken.

Doesn't policy say certain directories need to exist? Does it make assumptions about number-based children of higher level locations?

In this particular case, perhaps postgresql-client only accidentally worked, as one of it's dependents just happened to install a man-page into man1. A similar problem could occur if all earlier packages just had all their man-pages removed by each separate maintainer, such that nothing would be installed into man1/.

I'm not certain which way the bug should go.

@tianon

This comment has been minimized.

Copy link
Collaborator

commented Aug 9, 2017

@tianon

This comment has been minimized.

Copy link
Collaborator

commented Sep 30, 2017

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. 🎉

@yosifkit

This comment has been minimized.

Copy link

commented Nov 17, 2017

@j16sdiz

This comment has been minimized.

Copy link

commented Jul 11, 2018

The libc-bin and libpam-runtime package create the man1 directory comes with "Priority: required".
The debian policy reads:

The following priority levels are recognized by the Debian package management tools.

required
Packages which are necessary for the proper functioning of the system (usually, this means that dpkg functionality depends on these packages). Removing a required package may cause your system to become totally broken and you may not even be able to use dpkg to put things back, so only do so if you know what you are doing.

So, yes, they are required by the policy.

@tianon

This comment has been minimized.

Copy link
Collaborator

commented Jul 11, 2018

That's a bit of a stretch -- we're not removing the packages, but simply removing some unnecessary documentation files that they include, which makes this a gray area.

@j16sdiz

This comment has been minimized.

Copy link

commented Jul 12, 2018

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 .

mquinson added a commit to simgrid/simgrid that referenced this issue Aug 22, 2018
coverbeck added a commit to DataBiosphere/azul that referenced this issue Sep 20, 2018
Upgrade to nginx 1.15
Also removed Consonance, which is not being used.

Needed to explicitly create man1 and man7 directories, or
Postgres installation would fail. See
debuerreotype/debuerreotype#10 for details.
coverbeck added a commit to DataBiosphere/azul that referenced this issue Sep 20, 2018
Upgrade to nginx 1.15
Also removed Consonance, which is not being used.

Needed to explicitly create man1 and man7 directories, or
Postgres installation would fail. See
debuerreotype/debuerreotype#10 for details.
@gabegorelick

This comment has been minimized.

Copy link

commented Nov 13, 2018

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
@nicolaiskogheim

This comment has been minimized.

Copy link

commented Nov 19, 2018

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
@gabegorelick

This comment has been minimized.

Copy link

commented Nov 19, 2018

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

🤦‍♂️ Yes, sorry.

@paplorinc

This comment has been minimized.

Copy link

commented Dec 29, 2018

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

akamiya pushed a commit to fujisanmagazine/docker-ec-cube3 that referenced this issue Apr 7, 2019
Antonio Kamiya
change to use copy from local submodule instead of git clone at run-t…
…ime. added fix for bug in slim image (debuerreotype/debuerreotype#10). remove unused user creation. add env var to allow selection of database support (TODO: add dependencies based on selection). add sqlite3 support. fixed eccube_install.sh update. add env vars to allow setup of ec cube at runtime
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.