cask: simplify supports_linux?

[bevanjkay]

---

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
• Have you written new tests (excluding integration tests) for your changes? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) with your changes locally?

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes. Non-maintainers may only have one AI-assisted/generated PR open at a time.

I used claude-code to help debug the issue and implement the functionality.

---

Cask.supports_linux? previously returned false for casks that use on_linux do / on_macos do blocks without an explicit os stanza (e.g. winbox) https://github.com/Homebrew/homebrew-cask/pull/261129/changes.

When on_os_blocks_exist? is true but no os stanza value is present, this PR adds the functionality to simulate loading the cask on Linux and return true if either produces any artifacts.

[Copilot]

Pull request overview

Updates Homebrew Cask’s Linux-support detection so casks that use on_linux/on_macos blocks (but no explicit os stanza) can still be recognized as Linux-supported by simulating a Linux load and checking whether any artifacts are produced.

Changes:

• Enhance Cask::Cask#supports_linux? to simulate Linux loading when OS blocks exist but os stanza isn’t present.
• Add a new fixture cask exercising on_macos + on_linux artifacts and extend the supports_linux? spec accordingly.
• Change generate-cask-ci-matrix to default GITHUB_REPOSITORY to homebrew/cask.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
Library/Homebrew/cask/cask.rb	Adds Linux simulation fallback logic for OS-block-based casks without an os stanza.
Library/Homebrew/test/support/fixtures/cask/Casks/with-os-blocks.rb	New fixture cask with on_macos and on_linux blocks producing artifacts.
Library/Homebrew/test/cask/cask_spec.rb	Adds an assertion that the new OS-block fixture reports Linux support.
Library/Homebrew/dev-cmd/generate-cask-ci-matrix.rb	Defaults GITHUB_REPOSITORY env var value.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[MikeMcQuaid]

Thanks @bevanjkay! Appreciate this but think probably going down the wrong approach here.

I think @samford just added depends_on :macos to everything in homebrew/cask?

I think we should work with them and instead aim to reduce and remove all this logic around specific artefact checks and instead the # Bare depends_on :macos explicitly marks a cask as macOS-only logic above should be sufficient.

If anything, let's just add cask audits for casks using invalid artefacts for the OS.

[bevanjkay]

In that case I think we're looking at fairly large overhaul of the logic that determines if Linux is supported.

Essentially Linux is supported unless we say that it isn't? The same as how it works on homebrew-core?

For casks with more complicated artifact sets we are presently checking for the presence of the os dsl, but not checking for on_linux which doesn't really make sense. The cask could be laid out to interpolate with os and it would be detected as supporting Linux.

But if now is the time to hoist and reverse this logic then I'm ok with that.

[MikeMcQuaid]

Essentially Linux is supported unless we say that it isn't? The same as how it works on homebrew-core?

Yes, that's the goal here.

But if now is the time to hoist and reverse this logic then I'm ok with that.

Yes, I think so.

In hindsight: we should have done this in the first place. @samford has now done enough of the manual work here that I think we should be well placed to do how we should have done in the first place.

[bevanjkay]

I have simplified the logic significantly.
We don't have depends_on :macos implemented widely enough in homebrew-cask yet, so this PR is not mergeable.

---

Semi-relatedly, at the moment the below are seen as mutually exclusive;

  depends_on :macos
  depends_on macos: ">= :monterey"

and result in an error;

Error: Cask '<token>' definition is invalid: Only a single 'depends_on macos' is allowed.

However I think we need to be able to set both declarations - one for macos dependency, and one for minimum system requirement. A cask that is available on linux may still require a minimum macos version, so we need to be able to apply it there also.

[MikeMcQuaid]

However I think we need to be able to set both declarations - one for macos dependency, and one for minimum system requirement.

I agree we semantically need both but I think specifying both is pretty ugly so it'd be worth figuring out some other syntax for this like depends_on :macos, with_versions: ">= :monterey" or something?

[MikeMcQuaid]

@bevanjkay I'd suggest adding to this PR an audit that uses the existing invalid artefacts logic and fails on any cask that doesn't specify depends_on :macos. That will both prevent this PR from being merged prematurely and surface the casks that need fixed. Perhaps this could even be an autocorrecting RuboCop so we can run it on mass and it'll help third-party taps fix things too?