Fails when compiling [WAS: Re: [Announce] GPGME 1.0.0 released]

[Marcus Brinkmann]

At Fri, 01 Oct 2004 13:44:45 +0200,
Jose Carlos Garcia Sogo <jsogo at debian.org> wrote:
> > Of course, for real usability, you may want to make gpgme suggest or
> > recommend gpgsm.
> 
>   This will need to wait for a GpgSM package to be ready ;-)

Probably, if Debian Policy demands that.

> > I guess for the current release you might want to compile it without
> > gpgsm support.  It doesn't matter, but in either case I think a
> > dependency on the first gpgme version compiled with gpgsm support will
> > need to be added to the gpgsm package manually.
> 
>   Perhaps a enhaces. Or does gpgsm depends on gpgme (and gpgme on gpgsm,
> a nice circular dependency)

No, there is no hard-dependency in either direction.  GPGME will
detect if gpgsm is present or not, and provide proper information to
the user of the library.

However, let's say you install the GPGME enhanced mutt.  Then mutt
will depend on gpgme.  But to really use encryption, the user needs to
install at least either gpg or gpgsm, depending on which protocol he
wants to use.

Now, if GPGME requires GpgSM, or if GpgSM enhances, GPGME, I'll leave
that for the relevant maintainers to decide.  The only thing that
matters here in my view is that it will have the right consequences in
the user interfaces of the package installer frontends.

GpgSM will then suck in some libs and gpg-agent, which in turn will
suck in a pinentry package.  Those are hard dependencies, so it will
be OK.

>   Yes, but I am not very sure about Ägypten picture. I mean, I don't
> know which modules are needed, which is the canonical URL to get them,
> and IIRC Matthias Urlichs was also packaging some of these modules.

Yes.  Matthias Urlichs (who already replied, nice!) has also some
information about the package structure we sent to him some time ago,
and what I saw on his site matched that.  So, it's basically already
done.

The main issues from our point of view are that gpgsm, gpg-agent and
gpg should all be in their own packages, as gpg-agent can be used by
both (it probably "enhances" gpg, but is required for gpgsm).

Then there is the issue of package gpg2, which probably should be in
its own package, because of the major differences (some might prefer
the old one).  But then is the issue how to deal with it in GPGME.
You can either make an alternative GPGME package that is configured to
use gpg2, or you can manage gpg via alternatives in Debian (the latter
looks to me like the better solution).

Note that GPGME doesn't allow you to configure the path to the
backends at runtime.  This is a deliberate decision, for vague
security concerns.  However, if you look at it critically, there is no
real security to be gained from this, so we probably could be talked
into changing that, if it is actually helpful.  I am just mentioning
this as a potential third alternative.

Thanks,
Marcus