| Age | Commit message (Collapse) | Author |
|
|
|
This avoids linkage to both system Python and Homebrew's python.
|
|
This avoids having to fix formulae that use `python` to make them use
`python2`.
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Bob W. Hogg <rwhogg@linux.com>
|
|
|
|
|
|
|
|
It's redirected to cleartext, though this URL will be opened
in a browser so it won't be something hidden, and maybe
Oracle will fix this in the future.
|
|
Neither python nor python3 are available from Caskroom.
Signed-off-by: Bob W. Hogg <rwhogg@linux.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Split the core requirement class into generic, Linux-specific,
and macOS-specific parts.
Additionally, the Linux version is now able to detect Java versions
(the previous Linuxbrew implementation was only able to detect
if Java was present at all.)
|
|
This is cleaner, easier to understand how the arguments are split and
fixes #1799.
|
|
For example:
This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi
|
|
In the installation whose prefix is other than /usr/local,
osxfuse library and include path must explicitly be specified during build.
Although brew's pkg-config is configured to prepend appropriates paths,
the prepended paths (/usr/local) supercede the original HOMEBREW_PREFIX.
This behavior will cause the linker to select libraries outside brew's tree.
By adding /usr/local to HOMEBREW_LIBRARY_PATHS, superenv ensures that appears
only after the HOMEBREW_PREFIX, and thus fixes this problem.
HOMEBREW_INCLUDE_PATHS is also configured like keg-only Formulae.
|
|
formula_installer: Remove obsolete hard dependency on cctools.
|
|
ruby-macho now performs all relocations in Homebrew.
Additionally, delete the defunct CctoolsRequirement.
|
|
It's not used on enough configurations now that there's little point in
keeping it around. See e.g. `:autoconf` for prior art.
|
|
|
|
|
|
|
|
Sierra ships the headers/libraries still but for some reason decided to bin
the config scripts, which whilst seemingly not an issue for `mesos`
or `ganglia` it has broken `subversion`, `log4cxx`, `ctail`, `shibboleth`
and `passenger` that we know of so far. Let's assume more often than not
things are going to break without those config scripts around.
|
|
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.
|
|
|