Open gdejong opened 2 years ago
I'd personally lean towards this being the expected behavior of Alpine-based images (as in #1301, which is fundamentally the same underlying cause/issue). From the standard "Alpine" description on https://hub.docker.com/_/php:
To minimize image size, it's uncommon for additional related tools (such as
git
orbash
) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see thealpine
image description for examples of how to install packages if you are unfamiliar).
(Especially since an additional 29MiB is a pretty non-trivial bump, and it's not going to be all users of the image which require it.)
How likely is it to come across an app today that doesn't have to deal with internationalization in some way?
Maybe this deficit of Alpine images should be emphasized more clearly, or there should be another flavour: alpine-intl and alpine-en?
Also: this breaks (our) existing apps. If a smaller image is wanted perhaps that can be done at a major release instead of a bugfix release?
(and yes adding the package ourselves fixes the problem)
If you switch from the -alpine
variants to the -alpine3.15
variants, you will get the old behavior back.
@gdejong thanks for creating this issue! I've just spent 2.5 hours debugging why my dates were suddenly in English instead of the given locale. Fixed after adding icu-data-full
package or pinning Alpine to 3.15.
The problem isn't so much Alpine's philosophy, but the way consumers of the PHP Docker images have to deal with the various package availability changes made between Alpine versions.
As a user of this Docker image, let's say of tags 7.4-fpm-alpine
and 8.1-fpm-alpine
, it's unfortunate when packages that directly affect the behaviour of PHP change under my feet. Localization functionality in PHP that I may have been relying on is suddenly no longer available and I have to investigate why, just because it was decided to bump all supported images from Alpine 3.15 to 3.16.
From a user standpoint this is quite simply a backwards-incompatible change, or one that contributes to a Docker image tag being unstable. With some more careful consideration of package changes between Alpine versions, such unexpected breakages could be avoided. Much like @Mattie112 mentioned, Alpine version bumps make more sense in tandem with a minor version of PHP, I feel.
That said, I'll be adding icu-data-full
from now on, I suppose!
Unfortunately, the Alpine and PHP release cycles aren't in sync (or that would be more tenable), and users constantly want access to the newer Alpine releases, which is why we implemented more specific aliases (7.4-fpm-alpine3.15
, 7.4-fpm-alpine3.16
, 8.1-fpm-alpine15
, 8.1-fpm-alpine16
) for users to pin to specific releases and get themselves a more "stable" experience (with the understanding that they'll need to keep up with Alpine releases, but putting when to make those changes more in their hands than ours if they so choose).
Is it planned to add icu-data-full to the alpine 3.16 images?
If not, I fear that many developers will spend hours trying to understand why they get issues with dates.
If not, I fear that many developers will spend hours trying to understand why they get issues with dates.
your fear was right. https://github.com/php/php-src/issues/9365
The latest PHP images based on Alpine Linux now use Alpine Linux v3.16.
In v3.16, Alpine Linux has split the ICU package in two:
icu-data-en
andicu-data-full
.Only the
icu-data-en
package is now installed by default. The Alpine Linux changelog mentions this as well:This results in the following code not working as expected:
This now yields the output
Japanese
instead the expected日本語
. Other locale-related methods will probably also be affected.Would the Alpine-based PHP images want to include the
icu-data-full
package by default? Or is this package expected/intended to be not installed by default?See