Forbid using some formulas provided by macOS

[bugdea1er]

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

Homebrew needs a mechanism to disallow dependencies on a macOS provided formula when it is not considered a public API by Apple.

A good example of this is libarchive, and I'm sure there are others.

There is currently no audit that disallows uses_from_macos libarcive, even though macOS does not provide headers for it.

What is the motivation for the feature?

Recent discussions about using libarchive in formulas: see discussions in Homebrew/homebrew-core#183698, Homebrew/homebrew-core#183626 and Homebrew/homebrew-core#181569

TLDR: Apple's libarchive:

• lacks headers, which makes formulas more complex
• is old, provided only for backward compatibility, and lacks some functionality

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

This will guarantee that more formulas will work consistently across all supported platforms.

A good example of the problem is caveats for lanraragi formula:

def caveats
    <<~EOS
      Automatic thumbnail generation will not work properly on macOS < 10.15 due to the bundled Libarchive being too old.
      Opening archives for reading will generate thumbnails normally.
    EOS
  end

What alternatives to the feature have been considered?

Do nothing

This will lead to more discussions around new formulas which use libarchive and/or error-prone formulas that "jump through a lot of hoops to make it work and even then just get two plain header files"

[bugdea1er]

I think this also can be solved by not considering Apple's libarchive and other conflicting software as valid formulas.

Homebrew's libarhive will still be keg-only, but would it need another reason to be keg-only?

[MikeMcQuaid]

@fxcoudert @carlocab do you agree with the above?

[carlocab]

I'm ambivalent about forbidding usage of uses_from_macos "libarchive".

Most of our audits are designed to catch mistakes that are easy to make -- this one isn't very easy. And, in instances where it is easy (i.e. there are no hoops to jump through to use it), it's not clear that there's a hugely compelling reason to forbid it anyway.

To be clear, I'm not opposed to adding an audit or similar for it, but I'm similarly not convinced that we need one.

[MikeMcQuaid]

I'm ambivalent about forbidding usage of uses_from_macos "libarchive".

@carlocab Are we still using it in any formulae? Do we want to/not to?

[carlocab]

Are we still using it in any formulae?

There should be none remaining after Homebrew/homebrew-core#183698.

Do we want to/not to?

It's probably ok to use it if it doesn't require extra formula complications (like the ones removed in Homebrew/homebrew-core#183698, or discussed in linked PRs), but the possibility of that is small (e.g. requires the source tarball to provide the missing libarchive headers).

It may be safer to just use the libarchive formula always though, since it guarantees that we won't have mixed library versions. But libarchive pretty much never breaks their ABI, so I wouldn't worry much about mixed library versions either.

[fxcoudert]

To me the current situation rates as “fine as it is”. I don't think there is any great reason to use libarchive in homebrew-core formulas, but if there was a case, it wouldn't be a problem. The need is motivated by:

[the current situation] will lead to more discussions around new formulas which use libarchive

This was true when we had didn't have libarchive in provided_by_macos_depends_on_allowlist.json, but now I don't think it's true anymore.

[MikeMcQuaid]

Ok, thanks all, passing on this.