Auto-manage /usr/local/var/alternatives/<formula> symlinks for versioned <formula>@<version> formulae

[rkitover]

Provide a detailed description of the proposed feature

If the user installs, for example, llvm@13, create the /usr/local/var/alternatives/llvm symlink to the llvm version unless a version of the llvm formula is already installed.

The base formula would have the highest priority, followed by the highest version of a versioned formula installed, and the symlink would be updated on formula install/uninstall.

It may be worthwhile to have some kind utility to manage this symlink like update-alternatives in Debian, but this kind of automatic management should be sufficient for most people.

What is the motivation for the feature?

Making versioned formulae easier to use by both the user and brew itself.

One example is #13780.

How will the feature be relevant to at least 90% of Homebrew users?

It wouldn't be, versioned formulae are not often used.

What alternatives to the feature have been considered?

I don't have any.

[MikeMcQuaid]

If the user installs, for example, llvm@13, create the /usr/local/opt/llvm symlink to the llvm version unless a version of the llvm formula is already installed.

This would break backwards compatibility so: we're not going to do this.

We may be open to something like /usr/local/var/somethingnew/llvm being handled in this way, though.

Would that work for you?

[rkitover]

This would break backwards compatibility so: we're not going to do this. We may be open to something like /usr/local/var/somethingnew/llvm being handled in this way, though. Would that work for you?

Yes I think so, would you like me to submit a PR for this?

[MikeMcQuaid]

@rkitover Just to be clear: this won't change anything about how Homebrew itself works or uses e.g. LLVM but it'll perhaps make it easier to handle your PATH. Do you still want this given that?

I also wonder if the best fit for this may be a opt/llvm@any symlink or similar. Thoughts on that?

[carlocab]

At the risk of speaking for @rkitover (please correct me if I'm mistaken!), I think they are primarily interesting in this in order to be able to use a versioned llvm@* formula inside the llvm_clang shim.

Even if we do what's proposed here, I don't think we'll be changing the llvm_clang shim to allow for any installed llvm, so the interest in this change may be moot.

[rkitover]

Yes that was what I was thinking, but we should be able to do what we're discussing in #13780 without this, however that turns out.

This would slightly simplify my PATH handling, and I could see some small benefit for others, e.g. people use versioned postgres formulae.

I like the idea of opt/formula@any as well.

[rkitover]

Actually now that I think about it more, /usr/local/opt/<formula>@any would make the /usr/local/opt directory listing very spammy and ugly, so perhaps /usr/local/var/alternatives/formula would be better after all, or another directory of your choice.

Another question that is unrelated, how hard would it be for a third party like me to host bottles for an OS for which you do not provide bottles. If I were to, for example, set up a build server and web directory for bottles on my server, would that be possible? And if not, is that something you would consider supporting?

According to this High Sierra is not a completely dead OS, with 4.3% market-share. So I would consider doing something that like that if it were possible. High Sierra also has some interesting properties, like being the last macOS to allow using some powerful NVIDIA GPUs.

I would of course not expect any association, endorsement or even reference from your project if I were to do this. It would be a completely separate thing, I am just asking if you would consider allowing hooks for this, and I will do the necessary work.

[carlocab]

That's possible. See:

https://docs.brew.sh/Taps https://docs.brew.sh/Interesting-Taps-and-Forks https://github.com/gromgit/homebrew-core-mojave https://github.com/shivammathur/homebrew-php

[rkitover]

Nice, thank you.

[MikeMcQuaid]

Actually now that I think about it more, /usr/local/opt/<formula>@any would make the /usr/local/opt directory listing very spammy and ugly

My suggestion would be we only do this for formula with at least one versioned formula which should make it less so.

[rkitover]

My suggestion would be we only do this for formula with at least one versioned formula which should make it less so.

Yeah, that sounds good, thanks.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[rkitover]

@carlocab I just noticed that nix has llvm and clang 14 for 10.13, I will look at how to adapt their patches to the formula.

[carlocab]

MacPorts does as well. I think they're able to build LLVM for up to 10.10, but that relies on MacPorts-specific patches (they ship a special libSystem wrapper).

We can backport patches for the versioned LLVM formulae, but we should try to upstream fixes because we don't want to carry them indefinitely against the latest LLVM.

[rkitover]

We can backport patches for the versioned LLVM formulae, but we should try to upstream fixes because we don't want to carry them indefinitely against the latest LLVM.

I agree 100%.

I think for me to make any headway on this I need to start looking at how the existing patches were done, and in the process patch llvm@14, and then try to come up with a more general patch I can submit to the LLVM project using whatever workflow they are using.

Then we'd need to do the same for llvm@15, which is probably happening soon given the rcs.

By the way, no response or any comments on https://github.com/llvm/llvm-project/issues/57553 so far.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.