Php: Remove phpize deps from permanent image

[estahn]

Just wondering why we require perl in image php:7.1-fpm-stretch?

/usr/lib/x86_64-linux-gnu/perl => 19MB

# dpkg -S /usr/lib/x86_64-linux-gnu/perl
libperl5.24:amd64, perl-base: /usr/lib/x86_64-linux-gnu/perl

# apt-cache rdepends --installed perl
perl
Reverse Depends:
  autoconf
  adduser
  perl-base
  libdpkg-perl
  debconf
  libperl5.24
  perl-modules-5.24
  perl-base
  perl-base
  perl-modules-5.24

It appears to be related to phpize. Is there a need for it to be permanent in the image or could this be moved to a docker-php- script?

It's not relevant in production environments imo.

[estahn]

Seems like this is related to #513 #438 #557 #751 #716 which were all dismissed. Alpine is currently not an option as they have a major issue with DNS resolution (see https://github.com/gliderlabs/docker-alpine/issues/255)

[yosifkit]

could this be moved to a docker-php- script?

https://github.com/docker-library/php/pull/438#issuecomment-353695749

[wyqydsyq]

Debian does support virtual packages via the equivs utility and so these build-time dependencies should be easily manageable.

This has a disadvantage vs APK in that the virtual packages need to either be pre-baked .debs expressing the dependencies, or equivs will need to be installed and ran (then subsequently removed) in the Dockerfile build

Alternatively, the dependencies could just be explicitly removed after they are used. It's a bit messier but at least prevents bloat

I still don't see any good reasoning for why this support for phpize should even be included by default, it should be in a script or alternative image

[tianon]

I have yet to see a user of this image who didn't need at least one docker-php-ext-install, which requires phpize and the build dependencies to exist.

Our current variant/tag list is already _way_ out of control, so justification for a new variant is going to need to be very strong.

[estahn]

My current solution is to use multi-stage with a builder to add all dependencies and then copy everything (.so and bins etc) I need into the final image:

[brettpappas]

@estahn Would you be able to share your Dockerfile for your multi-stage build? I am in the same boat where I would like to trim the size of the stretch image down. I would love to use the alpine image but my build needs oci8 (w/ oracle instantclient) and it is not compatible with Alpine.

[jmrieger]

I have yet to see a user of this image who didn't need at least one docker-php-ext-install, which requires phpize and the build dependencies to exist.

I think that's an accurate and fair statement, which would also apply to the Alpine images. It doesn't preclude there being a better pattern for handling the build time dependencies - either a multi-stage build that does have the phpize dependencies, or modifying the docker-php-ext-* scripts to handle removing the Debian dependencies after the script is done running, similar to how they already handle apk. It's not the most efficient way to process in terms of build time, but it should be significantly more efficient in reduction of layer size.

I'll try to work out a proof of concept this week.

[tianon]

Alpine was given special treatment here specifically due to the
speed/efficiency of the apk package manager (especially thanks to having
an explicit --virtual flag to allow us to cleanly and correctly uninstall
only the things we caused to be installed). The same cannot be said of APT
(installing a package there is much more heavyweight, and it then becomes
more difficult to track which packages we caused to be installed versus
packages that were already installed).