Re: no{thing} build profiles
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.
Reply to: