---

This section details on the original issue you should resolve

<issue_title>Implement no_linkage DSL to cover dependencies without linkage</issue_title>
<issue_description>### 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

We sometimes have formulae with runtime dependencies that do not have linkage. One example of this is awscli. For that specific formula, cryptography is required at runtime, but there is no linkage:

╰─ brew linkage awscli
System libraries:
  /System/Library/Frameworks/Security.framework/Versions/A/Security
  /usr/lib/libSystem.B.dylib
Homebrew libraries:
  /opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib (openssl@3)
Dependencies with no linkage:
  cryptography

Given how much work we've done on fixing indirect dependencies with linkage, I think it's time to look in the other direction. I'm envisioning something like:

depends_on "cryptography" => :no_linkage

╰─ brew linkage awscli
System libraries:
  /System/Library/Frameworks/Security.framework/Versions/A/Security
  /usr/lib/libSystem.B.dylib
Homebrew libraries:
  /opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib (openssl@3)
Homebrew dependencies not requiring linkage:
  cryptography

Naturally I'm proposing the concept here, rather than the exact wording and implementation. This would ensure that all dependencies that should be linked are, and that all dependencies that aren't linked are confirmed.

What is the motivation for the feature?

Tightening up our formulae, ensuring that every dependency declared is used correctly. We already are performing audits for indirect dependencies with linkage, so this would close the loop.

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

It wouldn't be. It would simply help us with maintaining formulae.

What alternatives to the feature have been considered?

Status quo</issue_description>

Comments on the Issue (you are @copilot in this section)

@MikeMcQuaid @p-linnane we previously had `:run` and `:linked` that we could resurrect; some code still exists for them. Would either of those names make sense? I think `:run` did exactly what you want here. @p-linnane So rather than declaring that a dependency won't have linkage, we'd use `:run` to indicate it's a runtime dep without linkage? I think that could work. It doesn't feel very clear to me from the name though, since there will be all the other runtime deps that do have linkage. That was why I was proposing `:no_linkage` since it's very explicit in what's expected. Do you think we could lift some of the remaining `:run` code into a `:no_linkage`? @MikeMcQuaid > That was why I was proposing `:no_linkage` since it's very explicit in what's expected. Do you think we could lift some of the remaining `:run` code into a `:no_linkage`?

I think most of the code is gone. If you hate the :run name, cool, no problem, it's mainly just that it's a case that's previously been used.

I wouldn't be opposed to no_linkage or unlinked or something more explicit (provided it failed if there actually was linkage).</comment_new>
<comment_new>@p-linnane
It's not that I hate :run, it's just that I don't think it accurately describes what we're checking or confirming in this situation. Yes, it is a runtime dep, but the linkage is the thing we're primarily concerned about, since linkage happens with most runtime deps. I also agree it should fail if there is linkage, so we can investigate just like we do with the indirect deps with linkage. I'll think on it over the weekend.</comment_new>
<comment_new>@MikeMcQuaid
@p-linnane Cool, that's fair, I'm game for no_linkage or unlinked then.</comment_new>
<comment_new>@MikeMcQuaid
@gromgit Good shout, thanks for your input. I'm 👍🏻 to no_linkage.</comment_new>
<comment_new>@p-linnane
Assigned this to Copilot to see what it comes up with.</comment_new>