Package: libgpgme11
Version: 1.5.1-6
Severity: minor
[Apologies for not actually checking if the problem described is
relevant to Debian testing.]
Package: libgpgme11
[…]
Depends: gnupg2 (>> 2.0.4), […]
I believe that libgpgme11 should NOT depend on gnupg2 – in the
same way that, say, libcurl3 does not depend on Apache, nor does
libpq5 depend on the PostgreSQL server package.
Assuming that packages depending on libgpgme11 do so
in order to provide GPGME /as an option/ (and to satisfy the
respective run-time ld.so dependency; as it appears to be in the
case of Mutt; see below), I suggest downgrading the dependency
to Recommends: (with Conflicts: also added if necessary.)
Long story short, I’ve recently tried to install Mutt on a
“headless,” tty-over-SSH-only server. To my surprise, APT found
that it depends on libgtk2.0-0! Thankfully, no, Mutt wasn’t
upgraded to provide a GUI; the problem was in the
‘pinentry-gtk2’ package – which is required by gnupg-agent,
which is in turn required by gnupg2, and thus libgpgme11.
(JFTR, I’m aware of pinentry-curses.)
To make things weirder, Mutt doesn’t even /use/ GPGME in its
default settings (whether upstream or Debian; see below); but of
course being built with such support, the binary (or, rather,
ld.so) requires the library to run.
To quote /usr/share/doc/mutt/manual.txt.gz:
3.44. crypt_use_gpgme
Type: boolean
Default: no
This variable controls the use of the GPGME-enabled crypto backends. If it
is set and Mutt was built with gpgme support, the gpgme code for S/MIME and
PGP will be used instead of the classic code. Note that you need to set
this option in .muttrc; it won’t have any effect when used interactively.
And indeed, providing an otherwise empty, “fake” gnupg2 package
[1] made it possible to install and use Mutt with no obvious ill
effects (using [2] as the test file.) For instance:
• by default, ‘gpg’ command is used (per /etc/Muttrc.d/gpg.rc)
directly for signature checking; no GPGME calls are
(presumably) performed, hence little (if any) chance that the
‘gnupg2’ absence may affect Mutt operation in any way;
• when run with -e "set crypt_use_gpgme = yes", Mutt calls
GPGME, which appears to call the ‘gpg’ command in turn –
the one provided by the ‘gnupg’ (1.5.1-6) package in my case;
• finally, prepending also to PATH a directory containing ‘gpg’
and ‘gpgconf’ symlinks to /bin/false makes Mutt fail
gracefully when trying to verify OpenPGP signatures in the
messages.
From the above, I conclude that ‘gnupg2’ is not strictly
necessary to run Mutt (and presumably other packages built with
GPGME support), and thus per [3] (quoted below) should be
requested with Recommends: rather than Depends:.
This issue is perhaps less relevant to Debian testing, as there
GnuPG 2 finally replaced GnuPG 1. Still, it’s possible to rely
on the ‘gpgv’ package for OpenPGP signature validation (just as
‘apt’ does), and avoid the use of the full-weight ‘gnupg’
package. So, I would suggest using Recommends: for the
dependency there too.
[1] http://am-1.org/~ivan/dist/gnupg2_2.0.26-6+deb8u1_all.deb
SHA-256: 228ea1789f17e3a0fb81496327f76f1c95e740710dd147b005b5e8077aab1682
[2]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430213;mbox=yes;mboxmaint=yes
[3] http://debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
Depends
[…]
The Depends field should be used if the depended-on package is
required for the depending package to provide a significant
amount of functionality.
[…]
Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found
together with this one in all but unusual installations.
--
FSF associate member #7257
signature.asc
Description: Digital signature
