glib, glib-utils: merge #108307
glib, glib-utils: merge #108307
Conversation
BrewTestBot
added
the
automerge-skip
Formula/glib.rb
Outdated
| depends_on "pcre" | ||
|
|
||
| uses_from_macos "libffi", since: :catalina | ||
| uses_from_macos "python" |
There was a problem hiding this comment.
This does mean utilities won't work out-of-the-box on Mojave and older since they need Python 3, which could cascade into breaking dependent builds.
This is reason we originally didn't choose this approach as uses_from_macos "python", since: :catalina can trigger audit failure
There was a problem hiding this comment.
This does mean utilities won't work out-of-the-box on Mojave and older since they need Python 3, which could cascade into breaking dependent builds.
Mojave support is "best-effort" --
I don't think supporting Mojave can justify the hacks in glib-utils.
This is reason we originally didn't choose this approach as
uses_from_macos "python", since: :catalinacan trigger audit failure
What audit failure was that?
There was a problem hiding this comment.
We should adjust the audit then.
There was a problem hiding this comment.
If I had to guess, HOMEBREW_SIMULATE_MACOS_ON_LINUX is taking code paths of older version of macOS.
There was a problem hiding this comment.
What do you think about making this the oldest supported release of macOS?
Off the top of my head, I think that would be fine. Looks like there wasn't really much discussion about it when it was added, so probably fine.
CC: @Bo98
There was a problem hiding this comment.
The philosophy behind choosing the oldest macOS is that it includes the most dependencies (99.9% of the time). For auditing reasons this is usually a good thing.
We would have the same issue on Linux if the conflict audit wasn't disabled there. I would not rely on this remaining the case - I've been wanting to change that for a long time now.
The conflict audit failure here is really a special case. I'd say the way forward is to special case the python alias to not trigger the conflict audit, since those formulae are typically not bound to a particular version of Python. That's the real issue I feel.
There was a problem hiding this comment.
I've merged Homebrew/brew#13714. Now we only need #108343.
There was a problem hiding this comment.
| uses_from_macos "python" | |
| uses_from_macos "python", since: :catalina |
There was a problem hiding this comment.
Yep. This needs another run for the self-hosted runner and to rebuild some dependents against system libffi anyway.
We have an audit that checks each formula's dependency tree for multiple versions of the same software. We have an allowlist that allows us to ignore this audit, but this allowlist requires each formula with a conflict in its dependency tree to be listed there. Here, I propose the reverse: if formula `foo` appears in the `versioned_formula_dependent_conflicts_allowlist`, then all its dependents will not fail the versioned dependencies conflict because of a conflict with formula `foo`. I'd like to do this in the case of `python`, where I think the versioned dependencies conflict check hurts us more than helps us. Versioned dependency conflicts are most problematic in the case of libraries with the same install name but incompatible ABIs. This is almost never a problem with Python: almost no formulae link with the Python framework on macOS (in part due to one of our audits that disallows Python framework linkage in Python modules). Moreover, the various Python frameworks that we ship have the version in the install name. The above _might_ be a problem on Linux, since we allow unrestricted linkage with `libpython`. However, we don't even check versioned conflicts on Linux, so we aren't as concerned about this in the first place. This is also a lot more convenient than adding the dependents of some Python formula one by one as they acquire conflicts due to changes in other formulae. I've also amended `tap_auditor` to allow the use of formula aliases in an allowlist, to allow us to add `python` to this allowlist instead of each individual versioned Python formula. See also discussion at Homebrew/homebrew-core#108307.
The necessary PRs in Homebrew/homebrew-core have been merged. See: - Homebrew/homebrew-core#108307 - Homebrew/homebrew-core#108497 This reverts commit 6ca02b2.
The GLib utilities, which was split into its own `glib-utils` formula has been merged back into `glib`, see: Homebrew/homebrew-core#108307 This reverts commit a846de0.
The GLib utilities, which was split into its own `glib-utils` formula has been merged back into `glib`, see: Homebrew/homebrew-core#108307 This reverts commit a846de0.
`glib-utils` was removed in Homebrew#108307.
`glib-utils` was removed in #108307.
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install --build-from-source <formula>)? If this is a new formula, does it passbrew audit --new <formula>?glib-utilscurrently leans heavily on the implementation details of Meson. We have no guarantees of stability of that API, so this can break with any Meson update, and we wouldn't even know that it happened until the next timeglib-utilsis rebuilt.Let's get rid of it.
We can decouple
glibfrom a specific versioned Python dependency by usinguses_from_macos "python"instead. This does rely on our syntax check ignoring dependency conflicts of this type, but that's at least something we have control over (unlike Meson's internal API).While we're here, let's switch this to using
libffifrom macOS.The tap syntax check may fail from a number of formulae currently depending on
glib-utils. To avoid having to rebuild them, I may remove those dependencies in a separate syntax-only PR.Closes #107305.