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.
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.)
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.
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.
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.
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.
