This inappropriately modified the shared `patches` variable, meaning an
already fetched patch would be removed and therefore not be applied when
the resource was staged.
Also:
- when `brew test` or `brew postinstall` is run allow `Resource#stage`
to fetch the resource.
- make `Formula#fetch` and `Resource#fetch` fetch external patches too.
Follow-up from #7549 and #7546.
This API is used internally correctly and externally mostly correctly
but #6230 reveals the external usage is fairly confusing and a bit
unsafe by default. Preserve the existing API while verifying the
checksum by default and providing an opt-out. Using the existing, safe
method will result in a double verification of the checksum which is
harmless. A Homebrew/homebrew-core PR will follow shortly to address
those cases.
Fixes#6230
Fixes#5357
* Eliminates getting a new strategy instance via Resource methods
* only call resolve_url_basename_time once and store the time result as
an instance variable for reuse
Since patches sometimes change .gitignore and .travis.yml, it's
desirable to install them along with everything else if a resource needs
patching. Also, for resources that are git respositories, this allows
install to interact with git objects other than the commit specifically
checked out. More generally, this may help to avoid subtle issues by
preserving the fidelity of resources in cases where invisible dot files
play a functional role.
Closes#329.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
The new stage() signature introduced by #66 breaks back-compatibility
under Ruby 1.8.7. This fixes it by switching back to a one-argument
block signature and using a new class to wrap both the Resource and
Mktemp info for the staging context, in a signature-back-compatible
way.
Addresses homebrew/homebrew-core#529.
Closes#135.
Signed-off-by: Andrew Janke <andrew@apjanke.net>
Also enables sandbox for --interactive and --debug use of install
and test, using automatic retention.
Closes#66.
Signed-off-by: Andrew Janke <andrew@apjanke.net>
The "apply" DSL method can be called from patch-do blocks to specify
the paths within an archive of the desired patch files, which will be
applied in the order in which they were supplied to the "apply" calls.
If "apply" isn't used, raise an error whenever the extracted directory
doesn't contain exactly one file.
The "apply" method can be called zero or more times within a patch-do
block with the following syntaxes supported:
apply "single_apply"
apply "multiple_apply_1", "multiple_apply_2"
apply [array_of_apply]
If apply must be used, a single call using the second syntax above is
usually best practice. Each apply leaf should be the relative path to a
specific patch file in the extracted directory.
For example, if extracting this-v123-patches.tar.gz gives you
this-123
this-123/.DS_Store
this-123/LICENSE.txt
this-123/patches
this-123/patches/A.diff
this-123/patches/B.diff
this-123/patches/C.diff
this-123/README.txt
and you want to apply only B.diff and C.diff, then you need to use
"patches/B.diff" and "patches/C.diff" for the lowest-level apply leaves.
The code was provided by Xu Cheng. Any mistakes are mine.
