[Gpg4win-devel] [Announce] GPGME 1.1.7 released

[Igor Belyi]

Marcus Brinkmann wrote:
>> The latest gpg4win does not have this program and as a result,
>> gpgme-1.1.7 can't be used with it at all.
>>     
> Can you be more specific about the gpg4win version that fails for you?  We added
> gpgme-w32spawn.exe to gpg4win when we updated the gpgme version in gpg4win, the
> same time we added the bug fix.  Or are you mix-and-matching gpg4win with a
> self-compiled gpgme?
>> First, it would be nice to have that incompatibility documented.
>>     
>
> It's of course documented in the ChangeLog.  The NEWS file contains only
> user-visible changes, and this is transparent to the application developer.
>
> There is no unusual incompatibility here.  GPGME continues to be backwards
> compatible as advertised.
>   
I apologize for not explaining how I've run into this problem in the 
first place.

I maintain pyme project which is a Python wrapper for gpgme library. To 
build
this wrapper I need development components of gpgme (header and library) 
which
gpg4win installation does not provide and as a result I build 
libgpg-error and gpgme
myself. To use that wrapper on Windows I also need gpgme DLLs in the 
pyme module
directory. The idea is that pyme user should be able to use any 
encrypting/decripting
engine installed on their computer - it just the follow up on the GPGME 
claim that its
"API isn't restricted to this (GnuPG) engine".

So far I've based my Windows build on gpg4win 1.1.3 which is listed as a 
current stable
release. If I understood you correctly the gpg4win containing the 
updated gpgme is the
gpg4win 1.9.12 BETA and probably gpg4win 3.0.0 BETA1. I can try to 
create a separate
pyme build for these releases but I'd like to hear your suggestion 
regarding packaging
for pyme. I can't include gpgme-w32spawn.exe in pyme since gpgme DLL 
specifically
looks for it in GnuPG installation places. In Short, that pyme build 
will not be compatible
with gpg4win 1.1.3 or any other previous versions (see "backwards 
compatible as
advertised" above). On the other hand, I suspect that build with gpgme 
1.1.6 would still
work with gpg4win 1.9.12 (forward compatible?).

Also, with such change if somebody else decides to provide its own GnuPG 
implementation
they would have to make it Gpgme-enabled by including gpgme-w32spawn.exe 
as well.
This is perfectly reasonable design decision of course it just got me by 
surprise since
my understanding was that it was Gpgme job to be adapted to different 
engines and
not the other way around. Probably, it would be a bit more in agreement 
with me if
GnuPG engine would be specified with gpgme-w32spawn.exe as an executable 
instead
of still pointing to gpg.exe but spawning that other program instead.

I'd greatly appreciate your thoughts on this.

Cheers,
Igor