Bug#853102: [pkg-gnupg-maint] Bug#853102: libgpgme11: downgrade gnupg2 (gnupg) dependency to Recommends:
Hi Ivan-- On Sun 2017-01-29 13:57:19 -0500, Ivan Shmakov wrote: > [Apologies for not actually checking if the problem described is > relevant to Debian testing.] i'm not sure which exact problem is the one you think is most important, but if this is it: > 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.) then you'll be glad to know that the depenencies in debian testing are such that pinentry-curses is the only thing that would be installed automatically on a headless server. I think that's a reasonable tradeoff. Note that even on jessie, if you do: apt install pinentry-curses apt install mutt then you dont' get the heavyweight libgtk dependency chain. > 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. i believe (and hope!) that newer versions of mutt will use gpgme by default. > 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: this seems like a lot of work, compared to just manually installing pinentry-curses before installing mutt, no? > 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:. you're doing pretty heavy surgery on these tools in order to reach a "graceful" failure state. If you're ok doing that surgery, then i'm ok with you getting to deal with the aftereffects ;) As a maintainer, though, i'd really rather have the defaults Just Work. I agree with you that the default dependency chain in Jessie is too heavy (see https://bugs.debian.org/764292), but it's rather complicated to switch that around in jessie today. It will be better in stretch. :) > 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. I don't think that's technically correct, for either mutt or for libgpgme. gpgv is a specially-targeted tool, which expects a well-curated keyring and does not do any certificate validation or management. If there's a way that people are trying to use gpgv with mutt, i'd like to hear about it though! I'm going ahead and closing this bug because i think the underlying request has already been addressed quite some time ago in testing (see #764292, as mentioned above), but feel free to keep chatting here or on pkg-gnupg-ma...@lists.alioth.debian.org if you want to follow up. Thanks for the report, --dkg signature.asc Description: PGP signature
Bug#853102: libgpgme11: downgrade gnupg2 (gnupg) dependency to Recommends:
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
