Brew upgrading Python 3.11.5 -> 3.11.6_1 fails [macOS 12]

[awawa-dev]

Description

Installing Python 3.11.6_1 as an indirect dependency (azure-cli), causing an error and job failure.

==> Upgrading python@3.11
3.11.5 -> 3.11.6_1

==> Pouring [python@3.11--3.11.6_1.monterey.bottle.tar.gz](mailto:python@3.11--3.11.6_1.monterey.bottle.tar.gz)
Error: The brew link step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/2to3
Target /usr/local/bin/2to3
already exists. You may want to remove it:
rm '/usr/local/bin/2to3'

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• Windows Server 2019
• Windows Server 2022

Image version and build link

Current runner version: '2.311.0'
https://github.com/awawa-dev/HyperHDR/actions/runs/6897412769/job/18765513784#step:5:341

Is it regression?

regression, same command worked untill recently https://github.com/awawa-dev/HyperHDR/actions/runs/6827984819/job/18572890598

Expected behavior

brew installs required packages without error

Actual behavior

Fails to install Python 3.11 needed by needed azure-cli (Installing azure-cli dependency: python@3.11)

Repro steps

brew update && brew install qt@5 xz ccache zstd webp

[mikhailkoliada]

Hey, it is not a bug we can fix, it is expected behaviour of home-brew on any python update, you need explicitly call brew link --overwrite python@3.11 in your workflow to get a new link.

[awawa-dev]

But I don't use Azure-Cli or Python, so why am I forced to do this? In fact, the problem is that the current macOS runtime image contains a broken azure-cli package (or its dependency, none of them are used by me) and this is what causes the Python installation to fail. But yes, you can somehow get around this by removing azure-cli from the runner: brew remove azure-cli && brew update && brew install qt@5 xz ccache zstd webp and it works and as workaround is acceptable and better than configuring not used Python package with --overwrite.

[louwers]

We run into this problem. We are installing llvm@17 with brew install llvm@17.

Are you saying we need to update our workflow to bump brew link --overwrite python@3.11 to the new version every time there is a Python update?

[mikhailkoliada]

@louwers if it was not a part of the generated image, then yes, we can not do anything here, because a package "foo" conflicts with the symlinks from package "bar" (which are pre-existed by the time "bar" got updated), once new image release happens the latest "bar" is installed and symlinks are a part of the image.