New and improved `conflicts_with` handling for formulae and casks

[Rylan12]

Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

Right now, conflicts_with does not allow you to install two formulae or casks with conflicts with each other. However, in some cases, the two formulae should still be able to be installed and simply not both linked at the same time. Instead, we should handle this more intelligently by allowing side-by-side installs when possible, and simply avoid linking.

Here are some possible ways to handle this:

• Change the behavior of the conflicts_with DSL to allow side-by-side installs and handle conflicts on the linking end
• Add a new link_conflicts DSL (maybe in addition to conflicts_with
• In theory, we could move conflict handling to a .json file inside each tap. The only benefit of this that I can think of is that we wouldn't have to worry about making sure each conflicts_with/link_conflicts is properly paired with a corresponding entry in the conflicting formula/cask

What is the motivation for the feature?

Homebrew/homebrew-cask#12822, #16374, #16309, and others

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

This is relevant to anyone installing a formula or cask that conflicts with something else

What alternatives to the feature have been considered?

Leaving as-is

[Rylan12]

My thoughts:

I don't have a great grasp on how many formulae/casks we have right now that cannot be installed side-by-side (and just not both linked). If this number is not that many, I'd probably be in favor of changing conflicts_with since it seems the new behavior would be ideal for most cases.

However, if there are a lot of formulae that can't be installed side-by-side, then we should probably just move to a new DSL to minimize problems created for us and for other taps.

I don't think there's a good reason to go the JSON route really, since I think that should be reserved more for things like audits tap-wide maintenance stuff, not formula functionality

[MikeMcQuaid]

However, in some cases, the two formulae should still be able to be installed and simply not both linked at the same time.

My suspicion is: this is most, maybe all, cases.

Instead, we should handle this more intelligently by allowing side-by-side installs when possible, and simply avoid linking.

Agreed 👍🏻

For some prior art: we already do some relatively smart stuff here with versioned formulae linking and formula/cask linking when they have an identical name/token.

• Change the behavior of the conflicts_with DSL to allow side-by-side installs and handle conflicts on the linking end
• Add a new link_conflicts DSL (maybe in addition to conflicts_with)

I don't feel strongly either way here but @Homebrew/maintainers may do. With the prior we'll need to be fairly confident that we don't break things for third-party taps i.e. we should do this for Homebrew/homebrew-core first and verify no formulae changes are needed.

A middle ground is a conflicts_with parameter that changes the behaviour but is an opt-in (and we nudge towards it with audit/rubocops).

• In theory, we could move conflict handling to a .json file inside each tap. The only benefit of this that I can think of is that we wouldn't have to worry about making sure each conflicts_with/link_conflicts is properly paired with a corresponding entry in the conflicting formula/cask

👎🏻 from me but good to explore all options.

[github-actions]

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

[cho-m]

I think most handling will be fine for formula-cask conflicts and probably formula-formula on macOS.

On Linux, I would be worried about RPATH handling as I recall that we only save keg-only formula paths in addition to HOMEBREW_PREFIX/lib. Swapping brew linkage of a dependency can lead to a non-functioning formula (we've seen this before when libomp got picked up instead on llvm's copy and still see some linkage warnings on large dependent test CI runs).