[pkg-gnupg-maint] Bug#853102: libgpgme11: downgrade gnupg2 (gnupg) dependency to Recommends:

[Ivan Shmakov]

>>>>> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>>>>> On Fri 2017-04-07 09:37:27 -0400, Ivan Shmakov wrote:

 >> This was just to prove that circumventing the current Depends: and
 >> /not/ actually installing GnuPG does not result in unusable Mutt
 >> install.

 >> Hence, my reading of Debian Policy [3] is that in the mutt →
 >> libgpgme11 → gnupg dependency chain there’s at least one extraneous
 >> link.  And I don’t suppose it could be the mutt → libgpgme11 one,
 >> now could it?

 >> [3] http://debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

 > From that same reference:

 > The Depends field should be used if the depended-on package is
 > required for the depending package to provide a significant amount of
 > functionality.

 > libgpgme11 Depends: gnupg, because without gnupg, a significant
 > amount of libgpgme11's functionality (basically all of it) is lost.

 > So the libgpgme11 → gnupg link in the chain isn't wrong either,
 > right?

	I suppose the libraries are /de facto/ treated somewhat
	differently.  Consider, e. g., the following chain:

    exim4-daemon-heavy (Depends:) libpq5 (no Depends:) postgresql-9.6

	Now, there’s a considerable difference in that libpq5 may
	conceivably (and often will) be used to connect to a PostgreSQL
	server installed /somewhere else./ But there’s also a similarity
	in that it’s much less practical to avoid the first dependency
	than the second.  (There was a recent thread on that on
	debian-devel@, IIRC.)

	In effect, I’d say that the ‘significant functionality’ of a
	shared library package is to let the executables linked with
	that library run.  Whether the library functions will themselves
	get used depends on the executable and the particular use case.
	(Say, I wouldn’t mind an image viewer dependency on libjpeg even
	if I’m going to use that specific viewer only to view PNGs.)

 > I understand that you don't want to have any gnupg package installed
 > on your system, and that you want to have mutt installed.

 > It's conceivable that at some point in the future (it would
 > definitely not be before the stretch release), we could move both
 > gnupg and gpgsm to be Recommends: in libgpgme11,

	(And I hope to get a ping at that point.)

 > but i'd need to see a much clearer analysis of:

 > * gpgme's behavior when actually used in the absence of gpg.  what
 > kind of errors does it report?  how well does the library communicate
 > the reason for its failure to the application that's using it?

 > * commonly-used programs that link to gpgme — how do they respond
 > when gpgme reports that gpg isn't available?

	I’ve checked that Mutt behaves sensibly in this case already;
	I guess I can take a look at other reverse dependencies.

	Although given that there’s virtually no chance this change goes
	into Stretch, this hardly would be a priority for me right now.

	(… Perhaps some automated testing, too…)

 > I don't want a ton of bug reports saying "the tool gives me
 > incomprehensible error messages" that i have to respond to with "you
 > need to install the gnupg package".  That's a return to "DLL Hell"
 > which i don't want to take on.

	Given that recommended packages are installed by default since
	awhile, that’s somewhat unlikely to happen.

 > I'm sorry that you have a few extra packages installed on your
 > system, that you feel that they're bloat.  But the cost to the rest
 > of the ecosystem and the rest of the userbase of removing those
 > dependencies seems higher than the cost of you having a few more MiB
 > of unused software on your headless machine.

	I guess I will just avoid Mutt where feasible, or resort to
	installing a dummy ‘gnupg’ package otherwise.

 > I welcome any additional reports or analysis of the details above —
 > feel free to add them to this report (and if you see specific
 > problems, feel free also to report them upstream).  But doing that
 > analysis is not going to be high on my own priority list for debian
 > in the near future.

	ACK.

-- 
FSF associate member #7257  np. Digitalgarden — Chromag    3013 B6A0 230E 334A