Remove some unused packages

[hydrargyrum]

(This is a follow-up of monicahq/docker#109)

I see in a Dockerfile some effort is made to remove unused packages. But inspecting the resulting image, some packages seem questionable for a production image, for example autoconf, make, curl (command-line tool), dpkg-dev, gcc.
Those would be acceptable for an build-stage image where only required stuff would be installed/copied in the production-stage image. Furthermore, cleaning unused packages from a build-stage image would be pointless, so the apt-mark part would not even be needed.

% docker run --rm --entrypoint /bin/sh -it php:8.1-fpm -c "apt-mark showmanual"
autoconf
ca-certificates
curl
dpkg-dev
file
g++
gcc
libargon2-1
libbrotli1
libc6
libc6-dev
libcom-err2
libcurl4
libffi7
libgcc-s1
libgcrypt20
libgmp10
libgnutls30
libgpg-error0
libgssapi-krb5-2
libhogweed6
libicu67
libidn2-0
libk5crypto3
libkeyutils1
libkrb5-3
libkrb5support0
libldap-2.4-2
liblzma5
libnettle8
libnghttp2-14
libonig5
libp11-kit0
libpsl5
libreadline8
librtmp1
libsasl2-2
libsodium23
libsqlite3-0
libssh2-1
libssl1.1
libstdc++6
libtasn1-6
libtinfo6
libunistring2
libxml2
make
pkg-config
re2c
xz-utils
zlib1g

[yosifkit]

Those are all left on purpose so that extra extensions can be easily installed via docker-php-ext-install.

php/8.1/bullseye/fpm/Dockerfile

Lines 20 to 39 in 6598612

	ENV PHPIZE_DEPS \
	autoconf \
	dpkg-dev \
	file \
	g++ \
	gcc \
	libc-dev \
	make \
	pkg-config \
	re2c
	# persistent / runtime deps
	RUN set -eux; \
	apt-get update; \
	apt-get install -y --no-install-recommends \
	$PHPIZE_DEPS \
	ca-certificates \
	curl \
	xz-utils \
	; \

[tianon]

See also #438, especially #438 (comment).

[hydrargyrum]

If I understood it correctly, the pointed comment is about debian's apt-get purge not being good enough. I don't disagree with that. But if we want to avoid needless packages (@yosifkit implied they were actually needed for derived images), we could take the multi-stage approach:

• build/install whatever in a first image
• install only what's needed for production in a second image
• copy what was built in image 1 to image 2
• only publish image 2
• all of the above using a single Dockerfile!

[tianon]

The difficulty is not in what we build/include in the images (we can manage that), but rather that there are explicitly parts of PHP itself that we do not build in the images, but do support docker-ext-* for assisting users in installing in simple ways.