[gmime: 7/24] PORTING: No way to explicitly set the path to gpg as of gmime 3.0

[Jeffrey Stedfast <fejj src gnome org>]

commit 80e7e96e26c1f0fe44b9a0237210f4d1298817c5
Author: Daniel Kahn Gillmor <dkg fifthhorseman net>
Date:   Wed Jul 12 20:50:58 2017 -0400

    PORTING: No way to explicitly set the path to gpg as of gmime 3.0
    
    As of version 3.0, gmime is unable to explicitly set the path to the
    gpg executable.  in 2.6, it was possible to do so explicitly when
    invoking g_mime_gpg_context_new().
    
    This is a good thing, since The Defaults Should Be Correct™ :)
    
    It also acknowledges that different branches of gpg are really not
    actually effectively co-installable (that is, that they can't be used
    against the same homedir in a way that is usable).
    
    Furthermore, end users can still effectively select an installed
    version of GnuPG by setting $PATH properly, as long as the installed
    binary is named "gpg" in whatever directory it's located in.
    
    However, this is a change in functionality between versions, so i
    figure it's worth documenting it as something users need to think
    about.  For example, when building notmuch against gmime 3.0, we'll
    need to ensure that the "crypto.gpg_path" configuration option is
    explicitly deprecated.

 PORTING |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
---
diff --git a/PORTING b/PORTING
index 80de6d9..2ad6963 100644
--- a/PORTING
+++ b/PORTING
@@ -92,6 +92,11 @@ Porting from GMime 2.6 to GMime 3.0
 
 - Removed g_mime_gpg_context_[get,set]_auto_key_retrieve().
 
+- When using GMimeGpgContext, there is no longer a way to explicitly
+  set the path to the "gpg" executable.  Of course, users can still
+  use the $PATH environment variable to select any executable named
+  "gpg" as always.
+
 - Removed g_mime_crypto_context_[get,set]_retrieve_session_key(). This is now handled by
   passing GMIME_DECRYPT_EXPORT_SESSION_KEY to the g_mime_crypto_context_decrypt()
   method.