On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote:
This keeps getting repeated in this thread in spite of the fact that multiple people have stated that having libgpgme installed without gnupg is useful in a very reasonable scenario.
The scenario you describe, where the utility of the libgpgme package is soley as a way of satisfying a package dependency, and nothing to do with the bytes contained within the package, is an interesing case. It has taken me a few attempts to actually understand that this utility was what you (and Ivan iirc) were referring to. But it's not the traditional understanding of the utility of a package, and I don't think it's a purpose that was being considered when the relevant sections of policy were written.
Why are some maintainers so adamant about using Depends when Recommends is the correct dependency?
Because we don't agree that it is!
I'm going to use the neomutt → libgpgme → gnupg as an example, but this applies as well to any other case where someone has a legitimate use for installing one package without a dependency that would normally be found with that package. If libgpgme Depends: gnupg, then anyone who wishes to install libgpgme (or, in cases like this, a package that has a Depends: libgpgme) without gnupg must either use equivs to build a fake gnupg package or build a modified libgpgme package that does not depend on gnupg.
Both of Depends and Recommends in this case have drawbacks. It's a matter of weighing them up and considering their likelyhoods on a case by case basis. In this case, the maintainer must weigh the experience of users who may install mutt without gnupg and get a compromised experience, and how likely they are to hit that, versus the likelyhood that a user would be significantly troubled by installing gnupg even if they don't intend to use it; and in the latter case, factor in that we do have a system for addressing that, equivs, as you point out. In the case of mutt&neomutt, both are configured to have PGP enabled by default. With the default configuration, as soon as you read a PGP-signed mail, you will hit the behaviour that requires gnupg installed to function properly. Due to this, I don't think this functionality can be considered niché. Adam Borowski makes a compelling argument that it should be niché in another mail to this thread; but this should be reflected in the default configuration, IMHO, before any dependency strengths are altered.
However, if libgpgme Recommends: gnupg, then gnupg will be installed whenever libgpgme is installed, _unless_ the admin specifically prevents its installation.
By "specifically prevents its installation" you may be referring to a much older decision that the admin made to disable installing Recommends by default, possibly when they installed the OS. When the user runs mutt and the PGP functionality does not work, they may not necessarily relate that failure to their early policy decision, which might have been a long time ago. And that's a situation we want to avoid, especially for beginner users.
N.B. the policy definition of 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. That definition fits the relationship between libgpgme and gnupg perfectly.
It's vague definition with plenty of room for interpretation, on purpose, precisely so that a decision can be made factoring in all of the considerations outlined above on a case-by-case basis. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
