- Add homebrew_created_file? method to identify service files
- Add prepare_relocation_to_placeholders_for_homebrew_files method
- Modify replace_text_in_files to handle Homebrew files separately
- Homebrew-created files now get full path relocation instead of selective relocation
Co-authored-by: MikeMcQuaid <125011+MikeMcQuaid@users.noreply.github.com>
When `Enumerable#all?` is called without an argument, it should check
whether values are truthy but it doesn't appear to work as expected
for the `newer_than_upstream` hash. In this case,
`{ general: false }.all?` returns `true` when it seemingly should
return `false`. This is preventing autobump from opening PRs for new
versions, so I've updated related `all?` calls to use a block with an
explicit comparison to `true` as a workaround to fix autobump in the
immediate term.
I recently modified `bump` to show the upstream version even when the
formula/cask version is newer (instead of an opaque `Unable to get
versions` error) but I noticed an issue while reviewing output from
a recent autobump run in homebrew/cask. This change works as expected
for versions with only one part (e.g., 1.2.3) but some multipart cask
versions (e.g., 1.5,15039) aren't being handled like they should
(where we split on commas and compare the version parts separately).
As a result, a cask version like 1.5,15039 is incorrectly seen as
newer than an upstream version like 1.5.1,15145 because 15039 from
the cask version is being compared to 1 in the upstream version.
This addresses the issue by using `LivecheckVersion` objects in the
related comparison, so versions will be handled as expected. This was
an oversight on my part but it only affects one cask at the moment
(`ia-presenter`), so it wasn't a widespread issue.
Currently `brew bump` will output `unable to get versions` for the
livecheck (or Repology) version if it's lower than the current
package version. This makes it impossible to distinguish between a
failing livecheck and one where the livecheck version is lower. We can
detect when the package version is newer than the upstream version but
`bump` doesn't do anything to handle the situation.
This addresses the issue by updating `bump` to display the lower
upstream version and flag the current version with a trailing "(newer
than upstream)" parenthetical to make the situation apparent (and so
we can easily search for this text in the output).
This helps ld.bfd find the correct `glibc` dependency. Needed when using
host toolchain which will only search for /etc/ld.so.conf.
Also can help unsupported systems that force poured non-relocatable
`binutils` bottle.
`Cask::Audit.audit_livecheck_version` can raise a `key not found:
:latest` error when a hash from livecheck's `latest_version` method
doesn't have a `:latest` value. This error means that livecheck was
unable to identify the latest upstream version but it can only be
understood if the reader knows how this audit is implemented (and it
may also depend on knowing the structure of livecheck's
`latest_version` hash). Without that knowledge, the error doesn't
make it clear which audit is failing and why.
This addresses the issue by using `nil` as the default value for this
`fetch` call and accounting for a `nil` `latest_version` value. This
allows the audit to surface the usual "Version '1.2.3' differs from
'' retrieved by livecheck" failure, which makes it more clear that
livecheck isn't returning a version.
I ran `brew livecheck` today to check the packages in my watchlist
and realized that it wasn't checking one package because I had added
a trailing comment after the name (and `package # Comment` isn't a
valid package name). I thought we had added support for trailing
comments when we originally added comment support years back but I
must have been mistaken.
This adds support for trailing comments in livecheck watchlist files
as part of refactoring the watchlist line parsing logic to only use
one pass (instead of multiple `#map` and `#reject` calls). This
maintains the existing behavior, where blank lines and lines starting
with `#` are skipped, but does so in a more flexible manner. For
example, the existing logic wouldn't skip a comment line that has one
or more spaces before the `#` character but this new logic will
correctly skip it.
On the [beta Bluefin LTS](https://docs.projectbluefin.io/lts), `brew config` reports:
```console
OS: CentOS Stream release 10 (Coughlan)
```
This is due to the `/etc/redhat-release` file being prioritized over `::OS_VERSION` (`PRETTY_NAME` from `/etc/os-release`).
On Bluefin LTS, `PRETTY_NAME` is `Bluefin LTS`.
This commit reverses the order so `brew config` has better detection:
```
OS: Bluefin LTS
```
I tested on RHEL 10 and the OS line only changed in that the word
"release" was omitted:
```
$ cat /etc/redhat-release
Red Hat Enterprise Linux release 10.0 (Coughlan)
$ grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Red Hat Enterprise Linux 10.0 (Coughlan)"
```
- This is an improvement on my previous PR https://github.com/Homebrew/brew/pull/15788
We have some formulae and casks that contain both `deprecate!` and
`disable!` calls, presumably as a way of controlling the deprecation
behavior before the disable date is reached. However, once the disable
date has been reached, `Livecheck::SkipConditions` continues to skip
the package as deprecated instead of disabled. This isn't a functional
issue as the package is still skipped but it isn't accurate because
it's not being skipped as disabled.
This reorders `FORMULA_CHECKS` and `CASK_CHECKS` to run the disabled
check before the deprecated check, so the disable date will take
precedence when it's been reached.
