Would this be specific to binaries (or bottles containing binaries)?

Mainly as we use placeholder in text files to create all bottles.

@cho-m Yes, it should be binary specific and be indicated somehow in a bottle/tab/manifest so we don't break :all bottles. Anything that needs code signed would, by definition, not be possible to be :all.

and maybe Linux x86_64/arm64

This can help for formulae corrupted by binary patching, e.g.

• Bazel
• SBCL dependents (Incompatible with sbcl-dumped executables david942j/patchelf.rb#47)
• Various others mentioned in List of formula missing Linux bottles homebrew-core#86422 like gopass, oil, ...
• Protobuf dependents that are failing for some unknown reason after RPATH patching (or-tools: revision bump to test Linux failure homebrew-core#210944)

Only current option here is manual hacks to bypass the relocation logic (e.g. wrap the binary inside an archive so that brew bottle cannot see binary). Even non-relocatable bottles still use patchelf.rb and break binary.

Alternative would be to add DSL similar to NixOS to prevent patching, e.g. https://nixos.org/manual/nixpkgs/unstable/#var-stdenv-dontPatchELF

While I do agree it'd be ideal to use patchelf less (as it is fundamentally a hack), there's quite a difference between optimising the common path and suppressing a bug. We'll never be able to eliminate patchelf entirely for everyone, so suppressing it for the default path to avoid CI flagging genuine bugs is harmful as it will still be a problem that will affect some users. The fact CI is catching that bug is a good thing and it does raise a point that it's perhaps worth keeping a test for in brew test-bot should we make Linux not patch by default. The variables that require patching is more on Linux than macOS: different dynamic linker locations (such as brewed glibc) can trigger a patch rather than being just something for different prefixes.

(This is not me saying to ignore those problems - I just don't think suppressing it in CI is the correct approach. DSL is perhaps better depending on how it works for end users - not entirely clear to me how that works for e.g. a brewed glibc case.)

As an aside, to help out on those issues: I've looked into the protobuf examples just now and do see what's causing the issue - just not entirely sure yet what made it suddenly regress given it was working a couple months ago. Could do with further bisecting.

The fact CI is catching that bug is a good thing and it does raise a point that it's perhaps worth keeping a test for in brew test-bot should we make Linux not patch by default.

I do think we should still test the relocation path as part of CI run if the bottle is relocatable.

Though in the case that the bottle is not relocatable, I think bypassing some checks are fine. The main use case of patching non-relocatable bottle would be the --force-bottle usage which I would consider a lower supported tier / unsupported case.

Taking examples of SBCL-created executables and Bazel, in Homebrew/core we did end up skipping the test on Linux and just shipped broken Linux bottles, which seems worse to me than if we had shipped a bottle with non-patched binaries that only worked on default prefix.

Essentially would be nicer to match support tiers (#19248), e.g.

1. Prioritize default prefix and avoid patchelf that could corrupt bottle. This will reduce chances of accidentally shipping broken bottles.
2. Test relocation in CI for relocatable bottle. If it fails, we should have DSL to mark it as non-relocatable (currently we rely on bottle DSL with some pour_bottle? only_if: :default_prefix though a more specific DSL would be cleaner if we want to detail broken if patchelf-ed, etc.)
3. User is on their own if they try to pour non-relocatable bottle in non-default prefix

This will require more work to handle than ARM macOS case so can split this off into a separate issue tracker to consider after ARM macOS is done.

1. Prioritize default prefix and avoid patchelf that could corrupt bottle. This will reduce chances of accidentally shipping broken bottles.

I agree with this.

I don't think it makes sense for us to be talking about support levels and at the same time say that we need to ensure sufficient CI coverage of lower support levels that are, almost by definition, going to have lower coverage.

Relatedly, I don't think any maintainers should be or feel obligated to do work for unsupported configurations affecting a minority of users. If some maintainers want to: that's fine.

The "relocate by default" came about from days when relocating a /usr/local prefix (and repository, before ./Homebrew was used) simply wasn't reliable enough. It definitely is now, though, and @cho-m's argument adds weight to this.

The main use case of patching non-relocatable bottle would be the --force-bottle usage which I would consider a lower supported tier / unsupported case.

@cho-m Do you think it's worth adding this to #19641 to discuss support tiers? If so: where do you think it fits?