[Pkg-gnupg-maint] Bug#545275: priority important package depending on optional one.

[Daniel Leidert]

Am Dienstag, den 15.09.2009, 18:59 +0200 schrieb Julien Cristau:
> On Tue, Sep 15, 2009 at 17:55:27 +0200, Daniel Leidert wrote:> 
> > Am Sonntag, den 06.09.2009, 09:47 +0200 schrieb Andreas Metzler:

(JFTR: I saw your report against libcurl)

[..]
> > > You could perhapsr build gnupg
> > > twice (once to get a gpgkeys_hkp without curl and then a second time
> > > for gpgkeys_curl), but I have no idea whether this might actually
> > > produce working binaries or a subtly broken configuration, it is not
> > > something supported upstream. 
> > 
> > I would like to adjust this idea: gnupg (the gpg binary itself) does not
> > link against libcurl*. The curl library is only used for the helpers.
> > 
> > My suggestion would be: Build gnupg twice. First with "curl
> > shim" (without curl), then with libcurl-gnutls. The gnupg package will
> > then ship the binary and the helper tools without the curl dependency
> > (libldap is already downgraded to "Recommends"). A gnupg-curl package
> > could ship the helper tools built with libcurl and can be recommended by
> > gnupg. The tools can be handled via dpkg-divert. As David pointed out,
> > gnupg will happily communicate with both versions of the tools.
> > 
> If the gpg binary itself works fine without libcurl,

Should be the case. It doesn't link against libcurl. I can check that to
make it 100% sure.

> it seems to me you
> could just demote the hkp helper's dependencies to Recommends
> (exclude it when running dh_shlibdeps, and then run dpkg-shlibdeps
> -dRecommends on the helper?  This doesn't require splitting the package
> or messing with diversions.

I should have written that I considered this solution too, but decided
against it for two reasons:

(1) In fact by downgrading the libcurl-dep to a Recommends we create a
situation, where communication with keyservers in general is not
available. But I consider this an important part of the package.
Downgrading the ldap-dep to a 'Recommends' is already a compromise.
Doing this for all other helper tools too is IMO a no-go.

(2) There might be several packages (and IMO there are) of priority
standard or important which need to communicate with keyservers (using
gpg of course). They depend on working keyserver helper tools. So we
just move the problem from gnupg to these packages.

Regards, Daniel