[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



CCing d-devel to get some more feedback (@David, this is mostly FYI -
please comment if I'm wrong)

Am Sonntag, den 06.09.2009, 09:47 +0200 schrieb Andreas Metzler:

> the new gnupg now *depends* on libcurl3-gnutls. gnupg is priority
> important and a part of base system since debian-archive-keyring
> depends on it. (On a sidenote I am wondering whether splitting gpg
> and gpgv still makes sense if apt requires the full gnupg package
> anyway for apt-key.)
> 
> libcurl3-gnutls is only priority optional, breaking policy 2.5. Which
> makes this a rc bug. I am reporting this against gnupg instead of
> ftp.debian.org since I am not sure about the proper workaround.
> 
> There are two ways to fix this:
> #1 Bump libcurl3-gnutls priority. libcurl3-gnutls itself depends on
> ca-certificates (optional) which again depends on openssl (optional).
> I am pretty sure  we do not want to bump openssl's priority,
> libcurl3-gnutls should instead downgrade its dependency on
> ca-certificates to a suggests.
> 
> #2 Get rid of gnupg's dependency on libcurl3-gnutls. This seems to
> require quite a bit of effort.

As David pointed out, gnupg can be built without libcurl.

> If gnupg is built with curl support it
> is using curl even for hkp keyservers.

Correct.

> 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.

The rationale why I would like to build with curl is, that the "curl
shim" stuff has a few issues (timeouts for example; nothing serious) and
limitations. With the above solution we have a gnupg package that
fulfills the policy and is fully functional and helper tools, which
won't have the limitations and issues of "curl shim" for most users
(installing recommends).

The package will have to go through NEW but the queue is currently
pretty empty (with thanks to the FTP masters).

Comments, suggestions, votes (to the list or the bug report)?

Regards, Daniel

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Reply to: