php: Avoiding breaking changes such as PR #256

Hi,

PR #256 changed the way how it finds the installable packages, and then now I am no longer able to install third party packages such as PHPRedis using only docker-php-ext-install and have to rewrite all the existing Dockerfiles.

I’ve found some solution at https://github.com/docker-library/php/issues/262#issuecomment-233108680 which wraps the extension installation process with docker-php-source extract and docker-php-source delete, then adds the extension name to /usr/src/php-available-exts to “whitelist” the additional extension name. Obviously this solution “works as intended”, however, as you can see it requires all the developers to rewrite their customized php Dockerfiles.

The question is, why was this big breaking change applied to all the existing php Dockerfiles? Was there no option to create “a brand new version with breaking changes” and leave the existing Dockerfiles untouched? I have been using this php docker container for months on some enterprise-class solution, so I would like to avoid this kind of breaking changes to be happening as much as possible.

There is still last-resort solution which “copies the Dockerfile itself and customize the copied one,” however I think it’s not how this kind of publicly-used Dockerfile should be 😦

I would very much appreciated if you could consider not to make such a breaking change to all the existing Dockerfiles within the same version. Thanks!

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 5
Comments: 23 (11 by maintainers)

Most upvoted comments

@ktogo yes indeed:

docker-php-source delete should in fact run a mkdir -p /usr/src/php/ext after the code deletion.
The condition should effectively try to lookup into /usr/src/php/ext.

This should ensure BC whilst keeping the newly introduced feature that reduce produced container images size.

@ktogo will be in Japan for 2 weeks from Aug. 15th, but of course I expect that everything will be fine before that 😉

shouze on Jul 21, 2016

@shouze Both of move and docker-php-ext-install have failed. Even I added either docker-php-source extract or mkdir -p /usr/src/php/ext, it still failed at following line:

docker-php-ext-install redis

Regarding the revert solution, we need to consider that there might be some users who have already fixed their Dockerfiles by adding docker-php-source. The revert would let them face breaking change again, since docker-php-source command is introduced at PR #256 and it will disappear after revert.

To avoid this and recover the backward compatibility, I have another proposal:

Update docker-php-source delete to remove everything inside of /usr/src/php/ext, except the directly itself so that some codes such as mv phpredis-3.0.0 /usr/src/php/ext/redis would not crash.
Then, fix the conditional code here to lookup both /usr/src/php-available-exts and -d '/usr/src/php/ext'.

I haven’t tested this, but I guess this would probably solve the BC issue. Needs more thoughts.

ktogo on Jul 21, 2016