gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android

[Hans-Christoph Steiner]

On 02/20/2014 11:18 AM, Werner Koch wrote:
> On Thu, 20 Feb 2014 16:30, hans at guardianproject.info said:
> 
>> In this situation, PATH won't do anything useful by default on Android.
>> Android is not UNIX, apps do not install things into the PATH.  Also, apps are
> 
> You mean gpgconf is not installed in a directory listed by PATH?  Well,
> then why not hard code the directory for Android?
> 
>> not supposed to change env vars, that's inherited from Java, which only has
>> getenv(), no setenv().
> 
>> A hard-coded path to each thing that gpgme calls is the best approach that I
>> can think of for Android.  While technically possible to change the PATH, we
> 
> Okay - which path?  Build time configuration or runtime configuration?
> A fixed directory for Android seems to be the best appraoch

Yes, a build time config is perfect.


>> have wasted sooooo many hours with kludges like that.  Its not the right
>> approach for Android.
> 
> PATH is a standard Unix and Windows feature to locate executables.

That much I know... :)


>> to either implement gpgme in Java, or even better, implement a library that
>> talks directly to gpg-agent via assuan like the gpg command line do.  There
> 
> Actually gpgme is such a library.

I understand that gpgme is a wrapper.  The issue is having an Android wrapper
of a Java wrapper of a gpgme wrapper of gpg-agent is very hard to work with.
Having an Android wrapper of a Java wrapper would be a lot especially if
sometimes the Android native code can skip the Java wrapper and speak directly
to gpg-agent.

So I would like to discuss what needs to happen in GnuPG itself to enable us
to write such a thing.  This architecture would also work in other situation,
for example a python wrapper of gpg-agent.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81