At the moment, Microsoft Office and related casks fail audit due to
failure to fetch a product homepage from the main Microsoft site
(https://www.microsoft.com/) served by Akamai CDN.
The failure is severe and weird: no status code is received as the
connection is reset.
The analysis revealed the issue is linked to `User-Agent` and
`Accept-Language` headers parsing. Homebrew uses involved user agent
strings and has language hardcoded as `en`.
The simplest workaround is to use a simple user agent string when checking
homepage availability if the cask is in an audit exceptions list.
Merging this would fix Microsoft Office updates (including
https://github.com/Homebrew/homebrew-cask/pull/162671)
The `#audit_stable_version` check was previously part of
`#audit_revision_and_version_scheme` and duplicates some of the
logic to identify previous version information. To avoid the
duplication, this extracts the logic into a `#committed_version_info`
method that can be called in both audits. The method stores the
information in instance variables, so we don't repeat the collection
process if it has already run.
The "stable version should not decrease" formula audit currently
prevents us from being able to create bottles when downgrading a
formula version. We previously worked around this by bumping
`version_scheme` but this wasn't an intended use case and we now
avoid using it for this purpose.
We can handle simple formula downgrades by reverting changes in a
syntax-only PR but that isn't sufficient when we need new bottles
(i.e., if additional changes have been made to the formula in the
interim time). In the latter case, the only available solution may be
to revert all changes made after the previous version using a
syntax-only PR and then create another PR to reintroduce the other
changes and create new bottles.
To avoid the aforementioned approach, this splits the stable version
audit into a separate method, so we can use `brew audit
--except=stable_version` to selectively skip it.
- As discussed in
https://github.com/Homebrew/brew/pull/16337#issuecomment-1855668516,
then we won't have the chicken/egg problem of fixing cops for syntax
that's unsupported on Ruby 2.6 _before_ we set the TargetRubyVersion
to 3.1, but if we set it too early then all the taps will fail.
If an installed cask is invalid on attempting an untap: it will
prevent untapping that cask.
Fix this in two ways: one more specific to `untap` and one more
generally to other commands too:
- specific: only read the actual formulae/casks from the tap we're
untapping instead of all of those that are installed
- general: rescue more exceptions in `Cask::Caskroom.casks` (like we
already do for `Formula.installed`
This was not returning the full name correctly for e.g. anything in
Homebrew/homebrew-fonts.
While we're here, fix up a few other places where `tap.core_cask_tap?`
can be used more appropriately.
The idea here is that it should be expected that `brew upgrade` will
not upgrade pinned packages but will attempt to upgrade everything else.
For that reason, it will only show a warning about pinned packages
in that case.
If, on the other hand, you pass the name of a pinned package explicitly
to the upgrade command, like in `brew upgrade PINNED`, we want to show
an error since we cannot upgrade that package until it gets unpinned.
The hope is that this will be clearer and less annoying for users.
A user came to us a couple weeks ago stating that it was confusing
that the `brew upgrade` command printed an error when a pinned
formula had a new version available and didn't get upgraded.
This PR changes that message to a warning from an error. While looking
into this we found that there is another message that gets printed
when a package dependency doesn't get upgraded because it is pinned
and that got turned into a warning from a normal message. Honestly,
that should be more worrying for the user anyway; it could lead to
a program not working correctly in the worst case.
I also added a message to the `brew pin` command warning about
potential unintended behavior if a dependency gets pinned and another
package requires a newer version of it.
Lastly, I added a commented out deprecation notice for the
`brew upgrade --ignore-pinned` command since it's now the default.
