Re: no{thing} build profiles
* Matthias Klumpp <matthias@tenstral.net> [181021 14:04]:
> libgpgme is communicating with gnupg in the background - having
> libgpgme without gnupg itself will render the library completely
> unusable and break existing users of the library.
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.
> Also, gnupg/libgpgme are tiny, so you won't waste much disk space
> here.
See Steve Langasek's reply.
Why are some maintainers so adamant about using Depends when Recommends
is the correct dependency?
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.
However, if libgpgme Recommends: gnupg, then gnupg will be installed
whenever libgpgme is installed, _unless_ the admin specifically prevents
its installation.
With Recommends, everybody can get what they want: gnupg installed
unless specifically prevented. With Depends, preventing installation of
gnupg requires someone skilled and knowledgeable enough to build a
Debian package, as opposed to skilled enough to use aptitude's curses
mode.
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.
...Marvin
Reply to: