| Age | Commit message (Collapse) | Author |
|---|
|
info: print requirements
|
|
|
|
|
|
Not quite a mass replacement as I've used OS X and Mac OS X where
describing specific older versions and added compatibility methods
for things in the DSL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Removes the detection logic from the Requirement in favour of it living inside
the Gpg class & us calling it from there. It's a bit nicer & avoids us calling
Requirement code from outside of direct requirement handling & fulfillment.
|
|
GPG 1.x has stopped receiving new features, some of which we may well want to
take advantage of sooner or later in Homebrew. Upstream has also been attempting
to work out for a while how well used it still is which suggests it may "go away"
at some point in the future.
Debian is also in the process of migrating GnuPG 1.x to a `gpg1` executable
whilst GnuPG 2.1.x assumes the `gpg` executable. There's a detailed video
discussion of this from DebConf 2015 at:
http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/GnuPG_in_Debian_report.webm
It's unsafe to assume every `gpg` executable is going to forever equal 1.x and
every `gpg2` executable is going to forever equal 2.x. MacGPG2 has been symlinking
2.x as a vanilla `gpg` for a while, for example, and we will be soon as well.
You'll still be able to plonk the `libexec/bin` path of `gpg` in your PATH to
access a vanilla `gpg` 1.x executable if you want to, but we're not going to
actively keep adding gpg1 support to formulae going forwards. There's really no
reason why 99.9% of projects should not or cannot use `gpg2` these days.
This uses detection methods to determine regardless of what the executable
is called we're always hitting a 2.0 GnuPG or nothing.
|
|
Substitue each Version.new and HeadVersion.new with Version.create
to unify Version and HeadVersion instantiation among core code.
Note that this does not relate to Mac::OS::Version class.
|
|
|
|
We’re just supporting the Cask now.
|
|
We’re just supporting the Cask now.
|
|
Nicer to split this onto two lines.
|
|
Previously this was only using the last line.
|
|
|
|
This is in part designed to handle situations described in https://github.com/Homebrew/legacy-homebrew/issues/42273
where we tell someone to install a special dependency, but because we (rightly, IMO)
resolve special dependencies first users can end up being told to execute a command
on a tool that isn't yet installed and isn't immediately obvious how to install it.
In the situation raised there, with the `sile` formula people are being told to
`luarocks install xyz` but we hadn't installed Lua for them first, so they just
get a `command not found: luarocks` message. Perhaps it should be obvious enough
how to install said tools by looking at the formula's dependencies,
but it's not a huge burden on us to make life easier than that.
Shuffled over from https://github.com/Homebrew/legacy-homebrew/pull/42576.
|
|
|
|
|
|
Closes #118.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
|
|
|
|
Closes Homebrew/homebrew#47605.
Signed-off-by: Xu Cheng <xucheng@me.com>
|
|
|
|
|
|
|
|
This test wasn't running by default, so we missed that it wasn't
actually being executed - or that it was failing when running in the
testing environment.
As far as I can tell this is not, and has not, been used either in core
or in any tap, third party or otherwise, so just remove the feature and
its test.
|
|
Closes Homebrew/homebrew#45658.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
|
|
It made less sense to call a method `java_version` when it returns
boolean value.
Closes Homebrew/homebrew#45501.
Signed-off-by: Xu Cheng <xucheng@me.com>
|
|
The Emacs shell sets $EMACS to "t" for detection purposes, but it causes
builds to fail when they attempt to call Emacs using the variable.
Fixes Homebrew/homebrew-emacs#30.
Closes Homebrew/homebrew#45495.
Signed-off-by: Alex Dunn <dunn.alex@gmail.com>
|
|
see Homebrew/homebrew-emacs#29
Closes Homebrew/homebrew#45426.
Signed-off-by: Alex Dunn <dunn.alex@gmail.com>
|
|
|
|
This reverts commit 85271644b0083cbc0fd6fea71120d1ad859fbc2a.
Alex noticed that setting PYTHONPATH causes weirdness if we depend_on
something which may be optionally built --with-python3; PYTHONPATH
unexpectedly contains python3 modules in the depending formula if
the formula upon which it depends was built --with-python3 even
though the depending formula may only use python2.
Closes Homebrew/homebrew#43724. Closes Homebrew/homebrew#43744.
|
|
Closes Homebrew/homebrew#43453.
|
|
It's never used since a0a93f1b3b7b2be9b8a319be91086ffe220f8e32.
Closes Homebrew/homebrew#43462.
Signed-off-by: Xu Cheng <xucheng@me.com>
|
|
|
|
Merge branch 'bottle_hooks'
|
|
|
|
Install it as a dependency unless already satisfied by Xcode.
require cctools_requirement
cctools_requirement should be satisfied by cctools present in opt
add build_env => false to the satify block options in CctoolsRequirement
|
|
|
|
|
|
Fixes Homebrew/homebrew#42461.
|
|
|
|
Closes Homebrew/homebrew#42354.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
|
|
|
|
Dependency is another similar, related class and it's super confusing
to have some Requirements that are named *Dependency.
Closes Homebrew/homebrew#38891.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
|
|
1. Remove dead code (RubyRequirement always has a version)
2. Perfer `Utils.popen_read` instead of backticks.
|
