This provides an extra field to the GitHub Packages manifest about the
executable files in `bin` or `sbin` directories of the bottle.
It also provides an extra GitHub Packages JSON file with the list of all
files.
This would allow us (post a large rebottling effort) to start providing
this information in the Homebrew JSON API.
It also provides a much nicer information source for e.g.
homebrew-command-not-found that doesn't involve downloading actual
bottles.
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
- Remove use of (unused) `Cachable` module.
- Pass whether we're bottling to determine whether to create
reproducible SBOM or not. A reproducible SBOM omits the time and
compiler.
- Remove bottle information when bottling: we cannot know what e.g.
the checksum (and, with GitHub Packages, therefore also the download
location) will be before we've created the tarball contents.
- Always write a bottle on installation (unless we're bottling) to
provide new bottle information or freshen the existing one with the
information we stripped out for reproducibility e.g. the time and
compiler.
- Don't need to handle a `nil` `@source_modified_time` as it's always
set.
Fixes#17281
- write a schema when installing formulae (if not already present)
- cache the schema on disk rather than downloading it every time
- make more methods/attributes `private`
- allow validation to be optional, only enable for Homebrew developers
at installation time
- use the tab for more, correct information
- ensure that dependencies/bottles are written correctly
- use new SBOM 3 schema URL
- improve test coverage
This allows the correct bottling of `gnu-tar` dependencies (and
`gnu-tar` itself). It also installs `gnu-tar` at a more appropriate
time in the `brew bottle` command.
I noticed from
https://github.com/Homebrew/homebrew-core/actions/runs/5751070010 that
we're no longer creating reproducible bottles between macOS and Linux.
All macOS checksums have changed but Linux ones have not. The main
difference between the two platforms is the `gtar` version used so let's
always just use the formula on both platforms.
While we're here, clear up the ordering and comments a little on the
reproducible `tar` arguments so that it's easier to compare with the
reproducible builds archives documentation.
This commit includes `--no-mac-metadata` `--no-acls` and `--no-xattrs`
in `default_tar_args` for `brew bottle` command.
Although `default_tar_args` is only active when `--only-json-tab` is
not passed, in which case we don't require reproducible bottles, it is
nonetheless beneficial to "regularize" tarball creation. In
particular, this resolves a sporadic `brew tests
--only=dev-cmd/bottle:20` failure (see
https://github.com/orgs/Homebrew/discussions/4376 and
https://github.com/Homebrew/brew/pull/14997).
Furthermore, with `gnu tar`, `--no-acls` and `--no-xattrs` are default
flags. As for "mac metadata", although I couldn't find official
documentation, this post (https://superuser.com/a/61188) shares some
info:
- Resource forks (resource forks have been extended attributes since 10.4)
- Custom icons set in Finder and the images of Icon\r files
- Metadata in PSD files
- Objects stored in scpt files, AppleScript Editor window state, descriptions of scripts
- Information about aliases (aliases stop working if extended attributes are removed)
- Quarantine status or source URLs of files downloaded from the internet
- Spotlight comments
- Encoding of files saved with TextEdit
- Caret position of files opened with TextMate
- Skim notes
None of these is supposed to be in the bottle I believe.
- These are arbitrary length limits that had a load of disables in code.
- The limits were only increasing over time rather than decreasing.
- Fixing the problematic code to be shorter would take a long time for
questionable gain since the problem has been around so long.
- We're not going to make the really long things be any shorter any time soon.
- The instructions in issue 14685 say, pragmatically, "disable all the rubocop
rules we're never going to realistically fix e.g. Metrics/ClassLength". But
that felt like a slippery slope to more _really_ long modules/classes/blocks,
and the limits are here for a reason.
