brew/Library/Homebrew/requirements, branch 1.0.0 🍺 The missing package manager for macOS Use new "macOS" naming where appropriate. 2016-09-18T18:57:19+00:00 Mike McQuaid 2016-09-18T18:57:19+00:00 3f9cce0a03e967d2e7bcb7cd16bbc898c1a35708 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. 
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.
rubocop --auto-correct all hash-rocket usage. 2016-09-17T15:14:13+00:00 Mike McQuaid 2016-09-17T14:32:44+00:00 3982950e6106d45811a396a6a7478eeeee2817d7 






requirements/x11_requirement: fix Rubocop warnings.
2016-09-11T16:42:44+00:00

Mike McQuaid

2016-09-11T16:42:44+00:00

5cba530eef15ece440be63adb4d625018c97badc












requirements/ruby_requirement: fix Rubocop warnings.
2016-09-11T16:42:44+00:00

Mike McQuaid

2016-09-11T16:42:44+00:00

784e804fc23bbfa83a0104bb138f4802f8397d8a












requirements/perl_requirement: fix Rubocop warnings.
2016-09-11T16:42:44+00:00

Mike McQuaid

2016-09-11T16:42:44+00:00

dab681e71563b8d633d290f2f381a2101b56a3d8












requirements/java_requirement: fix Rubocop warnings.
2016-09-11T16:42:44+00:00

Mike McQuaid

2016-09-11T16:42:44+00:00

fb0e121686fa5212362d701b1d0dfb705c56c5d6












requirements/emacs_requirement: fix Rubocop warnings.
2016-09-11T16:42:43+00:00

Mike McQuaid

2016-09-11T16:42:43+00:00

7e42c5d08003fd38addbcd84af17df84e14a69b2












gpg_requirement: rename to gpg2_requirement
2016-08-13T02:33:33+00:00

Dominyk Tiller

2016-08-10T20:00:14+00:00

e02ad2242ab98f9ea7418ef51741480e3bfa4ed1












gpg_requirement: centralise logic in Gpg class
2016-08-13T02:33:33+00:00

Dominyk Tiller

2016-08-10T19:53:58+00:00

e62fc26b9ce05aee374cc7e32ca37ba8bb46d36e

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.





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_requirement: add standalone requirement
2016-08-13T02:33:33+00:00

Dominyk Tiller

2016-08-10T03:42:34+00:00

15916338888e48e70edc4ade7f0aff94e3607e76

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.





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.