Our docker builds are now failing after some updates this morning on DockerHub
Who is user doijanky and why are they updating all of the PHP packages today? Just today our PHP builds are failing after this person updated. (Docker Hub)
How do we report this problem?
#7 7.112 Some packages could not be installed. This may mean that you have
#7 7.112 requested an impossible situation or if you are using the unstable
#7 7.112 distribution that some required packages have not yet been created
#7 7.112 or been moved out of Incoming.
#7 7.112 The following information may help to resolve the situation:
#7 7.112
#7 7.112 The following packages have unmet dependencies:
#7 7.197 libodbc1 : PreDepends: multiarch-support but it is not installable
#7 7.198 odbcinst1debian2 : PreDepends: multiarch-support but it is not installable
#7 7.211 E: Unable to correct problems, you have held broken packages.
------
executor failed running [/bin/sh -c apt-get install -y apt-transport-https gnupg && curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add - && curl https://packages.microsoft.com/config/debian/9/prod.list > /etc/apt/sources.list.d/mssql-release.list && apt-get update -yqq && ACCEPT_EULA=Y apt-get install -y unixodbc unixodbc-dev libgss3 odbcinst msodbcsql17 locales && echo "en_US.UTF-8 zh_CN.UTF-8 UTF-8" > /etc/locale.gen && locale-gen]: exit code: 100
ERROR: Service 'php' failed to build : Build failed
I guess you know packages get updated all the time. Last Saturday Debian 11/bullseye was released, which seems to be related to this week’s PHP Docker updates. (But I’ve not thoroughly checked.)
Is this an older Debian 10/buster release? And did that work without also adding --allow-release-info-change in any apt-get update command? I’ve seen that being required if using buster, as the stable channel is now for Debian 11/bullseye, and 10/buster will now be referring to oldstable, throwing security errors without that extra flag.
Thank you for your reply. We did not add any other flags beyond changing the version number. I’m pretty new at using Docker so I did not know that packages get updated all the time.
I thought that once a package is out there and people are relying upon it, that it would not be changed, but rather a new version would be created. “latest” version not-withstanding. It caught us off guard because all of a sudden all our local docker stuff failed to build or compose up.
I’m unsure about what bullseye and buster mean? Are those Linux version names? The packager bot thingy (horribly named doijanky IMO-- like why not name it OfficalDockerBuildBot instead of some hacker type name I digress…) ran through and updated the Linux in the php 7.3-fpm package that was stable to a new unstable version and that broke our stuff. Now we know to add the specific version name to avoid “doijanky” and its update tricks.
After 2 years, 1 month, and 9 days of development, the Debian project is proud to present its new stable version 11 (code name “bullseye”), which will be supported for the next 5 years thanks to the combined work of the Debian Security team and the Debian Long Term Support team.
Well…, while that apparently works for that specific PHP image you’re using, it may not work for other (Debian-based) images if you apply some RUN apt-get updateyourself. If not cached, that command really gets today’s most up-to-date Debian package list (for the Debian version the image is based on), unaware it’s part of some Docker image with some specific version. And like I wrote, in other use cases the extra flag --allow-release-info-change will be needed when running that command on Debian 10 since last Saturday…
To be prepared, you may want to read the notes on apt-get in Best practices for writing Dockerfiles. You may even want to investigate why the build cache was actually not used in your case.
In our case, we were getting the same error because the python:3.9 tag was changed to bullseye last week. Any image that starts from that tag will have changed and may be similarly broken. Changing to python:3.9-buster fixed the issue for us. I assume that other python versions that don’t specify an OS version will have the same issue.