Package php5 have no installation candidate after latest changes

[igoralves1]

I have a dockerfile that is using this baseImage: https://github.com/docker-library/php/blob/6677546d599d3980781b520f84d03ecaad291dd1/5.6/jessie/apache/Dockerfile

Last time I built an image was 2 or 3 weeks ago. It was working good.

Today I've try to build again but I just got some erros.

Basically 'has no installation candidate' for almost all modules I was using. Here is an example:

Step 9/177 : RUN apt-get install -y php5-common
 ---> Running in 8eb9555275bc
Reading package lists...
Building dependency tree...
Reading state information...
Package php5-common is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'php5-common' has no installation candidate
The command '/bin/sh -c apt-get install -y php5-common' returned a non-zero code: 100

I see that some changes have been made in the last 2 weeks and that could be the origin of the issue.
https://github.com/docker-library/php/commits/6677546d599d3980781b520f84d03ecaad291dd1/5.6/jessie/apache/Dockerfile
How can I get the old version back?

thanks

[tianon]

See #542 and the linked issues -- when you install php5-common from Debian, you install a second copy of PHP, and not the version you're intending to use from this image.

Why are you trying to install php5-common in the first place? It shouldn't be necessary, and definitely won't work properly with the PHP provided by this image.

[mstenta]

I need to install phpunit and php5-geos - what is the recommended way to do this now?

[mstenta]

Is there any other way to accomplish #542 without breaking backwards compatibility? This essentially means that the tagged release I just made of farmOS will never have a working Docker image. But if this were rolled back or made less destructive in this repo, then I could trigger a rebuild.

[MrMMorris]

So luckily all I had that was breaking was php5-cli, but I think this change is going to break a lot of builds and result in a lot of confused people. This would be fine if there was an easy way to revert to a previous image, but it will be overwritten due to there being no version increment. This means people either will have to fix the issues immediately, build their own images which is a slippery slope, or hope they still have the old images somewhere which is not very robust.

Is there a less destructive way to make this change @tianon? Maybe having an -old config image that people can use in the meantime while they fix the issues?

[mstenta]

Personally, I think #542 should be reverted until a better approach can be figured out.

The goal of #542 was "help folks with the confusion around installing packages". Maybe it does that for new users - but it CAUSES more confusion and pain for existing users. One step forward, two steps back.

If #542 is reverted, then builds will magically start working again without any work required from their maintainers (except maybe some manual rebuilds, but no code changes).

[mstenta]

Created a pull request to revert the pull request. :-)

#554

If there's a better way to do this, let me know. I figured I would make this pull request to make it easy for the maintainers to roll back #542 if they want to.

[igoralves1]

@mstenta If you need, this is what I have to phpunit in my Dockerfile.

RUN curl https://phar.phpunit.de/phpunit-5.6.0.phar -L -o phpunit.phar
RUN chmod +x phpunit.phar
RUN mv phpunit.phar /usr/local/bin/phpunit

[yosifkit]

When you install php* packages from Debian, you install a second copy of PHP (or at least some of its modules), and not the version you're intending to use from this image. Everyone who has been doing so, has possibly not been using the php from this container (and instead the using the one they install from Debian). In that case, they would be better off using FROM debian:stretch. #542 was to prevent the situation since the installed packages from Debian are not guaranteed to work with the php in the image.

Take for example installing phpunit which pulls in a second copy of php with php5-cli:

$ docker run -it --rm php:5.6 bash
root@b50160ab1c68:/# rm /etc/apt/preferences.d/no-debian-php
root@b50160ab1c68:/# apt-get update
...
root@b50160ab1c68:/# apt-get install phpunit
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  javascript-common libjs-bootstrap libjs-jquery libjs-jquery-metadata
  libjs-jquery-tablesorter libjs-twitter-bootstrap libjson-c2 libonig2
  libperl4-corelibs-perl libqdbm14 lsof pear-channels php-codecoverage
  php-doctrine-instantiator php-file-iterator php-pear php-symfony-yaml
  php-text-template php-timer php-token-stream php5-cli php5-common php5-json
  php5-readline phpunit-comparator phpunit-diff phpunit-environment phpunit-exporter
  phpunit-mock-object phpunit-version psmisc ucf
Suggested packages:
  libjs-twitter-bootstrap-docs php5-xdebug php5-dev php5-user-cache phpunit-dbunit
  phpunit-selenium phpunit-story php-phpunit-php-invoker
The following NEW packages will be installed:
  javascript-common libjs-bootstrap libjs-jquery libjs-jquery-metadata
  libjs-jquery-tablesorter libjs-twitter-bootstrap libjson-c2 libonig2
  libperl4-corelibs-perl libqdbm14 lsof pear-channels php-codecoverage
  php-doctrine-instantiator php-file-iterator php-pear php-symfony-yaml
  php-text-template php-timer php-token-stream php5-cli php5-common php5-json
  php5-readline phpunit phpunit-comparator phpunit-diff phpunit-environment
  phpunit-exporter phpunit-mock-object phpunit-version psmisc ucf
0 upgraded, 33 newly installed, 0 to remove and 1 not upgraded.
Need to get 4825 kB of archives.
After this operation, 20.7 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
...
root@b50160ab1c68:/# php -v
PHP 5.6.32 (cli) (built: Dec 19 2017 00:54:21) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
root@b50160ab1c68:/# php5 -v
PHP 5.6.30-0+deb8u1 (cli) (built: Feb  8 2017 08:50:21) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

[mstenta]

@igoralves1 - Thanks! I found a good workaround for my purposes - using libgeos-dev instead of php5-geos. I also found that phpunit isn't necessary for me anymore. So I'm all set moving forward.

@yosifkit - Thanks for the explanation - it makes sense. I'm curious what the rationale was for not using the Debian packages in the first place. Was it to avoid version lock-in when distros don't update their packages? I assume the custom approach is also why you need to use docker-php-ext-enable and other custom commands in this image?

Still disappointed that this change broke my latest tagged Docker image on Docker Hub, though - and means I won't have a working "stable" (non-dev) image until my next release. My vote would still be to roll back this change and figure out if it would be possible to find a non-BC-breaking alternative approach - because I assume others may be in a similar boat. But if not, I'll just live with it until the next release of farmOS.

[tianon]

As to why we used PHP's upstream releases instead of Debian's packages, we did so because all the official images strive to use the method upstream recommends and supports. If all we did was install the Debian package, we'd not only be going against upstream's officially most-recommended installation method (https://secure.php.net/manual/en/install.unix.php), but we'd also not be providing any value over our users just using a three-line Dockerfile of their own to install PHP from Debian (which they're still free to do).

In addition, as you referenced, we wouldn't be able to keep up with upstream's releases (since Debian will only update PHP in a stable release if there's a security vulnerability). We run into this exact issue on a regular basis over in the OpenJDK official image (since OpenJDK is notoriously non-trivial to build from source).

This change was made to make it clear (in the form of outright package errors which are trivial to work around by removing the offending file, as pointed out by @yosifkit's example above) to users of this image that if they're installing Debian's PHP packages, they're already creating images that are doing something unexpected at best, and in most cases something completely incorrect. It is not likely to be reverted, but we have been contemplating adding a very short blurb to the image documentation about using rm /etc/apt/preferences.d/no-debian-php to workaround this (with strong wording explaining that it will likely result in at least two different versions of PHP being installed simultaneously, which is almost never something useful or desirable).

[tianon]

Documentation PR filed: docker-library/docs#1111

[mstenta]

Thanks for all the info! Makes sense. Appreciate the response and all the hard work on this project. 👍