Re: no{thing} build profiles
On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote:
> * 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.
I'd say this applies to _majority_ of users.
You and me are some of rare people who actually use gnupg (other than for
signature verification embedded in apt which doesn't use the program
itself). Heck, I even use gpg with mutt. On two machines. Out of a couple
tens of computers (I no longer work as a sysadmin, so the number fell).
So even for me, gnupg is useful on less than 10% of installs. And ordinary
users (including sysadmins) don't use it at all these days.
> Why are some maintainers so adamant about using Depends when Recommends
> is the correct dependency?
I say neither is correct here.
> 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.
This results in gnupg being installed for no reason, just because a small
minority of users might want it.
Having [neo]mutt compiled against libgpgme is very useful -- it's an
optional feature we want. Like, quite a portion of you want libsystemd (for
optional features _I_ don't want) -- but all it costs me is a tiny bit of
space. With typical compiled languages, dlopening is hard, tedious and
error-prone, so we just enable all optional libs.
> 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 doesn't fit it at all. Note the wording "in all but unusual
installations". As I mentioned above, I -- a DD with a gpg key -- use gnupg
on less than 10% machines. Out of non-DDs/DMs/DCs I'd estimate[1] less than
1% even know how to use gnupg. Yet at least among sysadmin types, mutt is
quite popular. Thus, gnupg would be found together with mutt (thus
libgpgme) in only unusual installations...
Thus, I'd re-propose a Policy change that was mentioned in multiple threads
in the past:
"A runtime library should not Depend: or Recommend: on any packages than
other libraries or dormant data, unless the library or its programming
language provides a convenient scheme for it being loaded only optionally.
Any such dependencies should be declared by programs linked against such
a library."
Ie, if you're libwrap0, you don't Recommend: tcpd, this decision is made by
openssh-server (wants tcpd only very rarely), gdm3 (almost never) or
leafnode (no other access control thus almost always). Dropped in #855919.
Meow!
[1]. Via scientific rectal extraction.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄⠀⠀⠀⠀ and 1 who narrowly avoided an off-by-one error.
Reply to: