admin/brew
1
0
Fork 0
Code Issues Packages Projects Releases 6 Wiki Activity
brew/Library/Homebrew/requirements/gpg2_requirement.rb

13 lines
353 B
Ruby
Raw Normal View History

gpg_requirement: add standalone requirement 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.
2016-08-10 04:42:34 +01:00
require "requirement"
gpg_requirement: centralise logic in Gpg class 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.
2016-08-10 20:53:58 +01:00
require "gpg"
gpg_requirement: add standalone requirement 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.
2016-08-10 04:42:34 +01:00
gpg_requirement: rename to gpg2_requirement
2016-08-10 21:00:14 +01:00
class GPG2Requirement < Requirement
gpg_requirement: add standalone requirement 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.
2016-08-10 04:42:34 +01:00
fatal true
gpg2_requirement: set default_formula to gnupg (2.1.x)
2017-03-15 14:53:18 -04:00
default_formula "gnupg"
gpg_requirement: add standalone requirement 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.
2016-08-10 04:42:34 +01:00
gpg2_requirement: update code comments
2017-08-29 05:20:10 +01:00
# GPGTools installs GnuPG 2.0.x as a `gpg` symlink pointing
# to `gpg2`. Our `gnupg` installs only a non-symlink `gpg`.
# The aim is to retain support for any version above 2.0.
gpg2_requirement: flip search priority
2017-08-09 17:02:14 +01:00
satisfy(build_env: false) { Gpg.gpg || Gpg.gpg2 }
gpg_requirement: add standalone requirement 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.
2016-08-10 04:42:34 +01:00
end
Reference in New Issue Copy Permalink