Replace pkg-config with pkgconf when the distribution is brew

[mseri]

Import #26878 with only the latest pkg-config-file updated (in case there are users still using older copies of homebrew)

[mseri]

This was already tested

[hannesm]

First of all, thanks for your work on the opam-repository maintenance :)

Hmm, I'd have expected to bump conf-pkg-config in the version number... now it is unclear when someone reports a failure in conf-pkg-config.3 what their brew depext candidate is/was.

Furthermore, from my brief understanding, a recompilation for everybody using conf-pkg-config could have been avoided by bumping the version number (conf-pkg-config.3.1) and mark that as available: ... = os = "macos" & os-distribution = "homebrew"}.

But I may be wrong, I'm a bit unhappy about unversioned conf-* package upgrades in general (adding distributions is usually not an issue, but modifying existing filters etc. is dangerous - I remember some breakage in the past), but if this is considered to be a good idea, please go ahead.

[mseri]

You are right, of course. The reason I decided not to bump the version in this case, is that almost every macOS user that uses homebrew uses the head of their packages branch. For all the others, who would see a failure with the new release, pending to 3.1 or to 2 would give the exact same package. So I thought maybe this is one of those points in which we can avoid creating a new package since version 2 would be exactly equivalent for those user to version 2. With metadata changes if this type this is something we have done other times. But I agree, maybe we should’ve just done a new version to avoid any confusion.

[mseri]

Furthermore, from my brief understanding, a recompilation for everybody using conf-pkg-config could have been avoided by bumping the version number (conf-pkg-config.3.1) and mark that as available: ... = os = "macos" & os-distribution = "homebrew"}.

I thought with recent opams this should not happen unless you are on the system that was affected by the change. But I am absolutely not sure about it 😅

[SkySkimmer]

This seems to have broken our CI and the fix I found looks a bit strange https://github.com/coq/coq/pull/19836/files
Are we doing something wrong?

[hhugo]

I'm seeing failure that look related to this. https://github.com/ocsigen/js_of_ocaml/actions/runs/11914383047/job/33202182023
@mseri, any help to fix this would be welcome

[mseri]

The github runners have pkg-config, the old homebrew package, preinstalled and it conflicts with the new one. What's worse, is that unlinking the old one allows the new one to be installed but the symlink that they create to pkg-config seems to not work on the runners.

There are two options that I have seen working so far:

• force the installation of conf-pkg-config.2 for macos (fine also for linux)
• run brew unlink pkg-config; brew install pkgconf; brew link pkg-config beforehand
• run brew update; brew upgrade; brew install pkgconf from Issue with brew package pkgconf actions/runner-images#10984

I am going to suggest an updated conf- package that should work with just brew unlink pkg-config, but there is no guarantee that that will work out of the box on the GitHub runners until they fix this (in homebrew or in the runners)

EDIT: updated with @hhugo workaround

[mseri]

I suggested a new release, but it will not completely solve the problem. The runners are using an outdated package that conflicts with the new one and it seems that they have an issue with the symlink created by the new package (it is not found by opam)

[hhugo]

I've fixed my issue with ocsigen/js_of_ocaml#1737