[pkg-gnupg-maint] Bug#891931: Bug#891931: gnupg: semantic change of the package to a meta-package results in upgrade bloat

[Daniel Kahn Gillmor]

Control: tags 891931 + wontfix

Hi xnox--

Thanks for reporting this concern.  I don't agree with the strategy you
propose below, but i appreciate the opportunity to explain my reasoning.
I'm marking it "wontfix" so that my intent on packaging is clear, but
I'm fine with continued discussion on it if you like.

On Fri 2018-03-02 17:59:53 +0000, Dimitri John Ledkov wrote:
> Above resulted, in many guides and low-level tools forcing and
> hardcoding installation of the `bin:gnupg' package. For example,
> live-build / deboostrapping tools still hard code installing
> `bin:gnupg' package, enough though `bin:gpgv' is sufficient for
> secure-apt.

agreed.  this is a bug in those tools, and we should encourage them to
switch to gpgv.

> Some of the `bin:gnupg' users are running very minimal systems, and do
> need key management. Thus these systems upon upgrade, would exect to
> stay minimal, and thus "upgrade" to the `bin:gpg' package.

yes, those packages that need minimal configuraton should stay with
"bin:gpg".

> This is unacceptable. We are in the process of fixing and dropping the
> usage of `bin:gnupg' or replacing it with more granular packages as
> appropriate.

Great, thanks!  Having the capacity for that granularity was exactly the
point of this upgrade.

> However, I believe it is confusing to have two package names with very
> similar names (gnupg & gpg), and I believe very little people are
> aware of the fact that interactive/desktop systems probably want
> `bin:gnupg' whilst all automation scripts need updating from gnupg ->
> gpg package names, conditional on existance of gpg.

I don't think i agree with the global assessment that
interactive/desktop systems want the full suite and automation/scripts
want the piecemeal/granular installation.  There are certainly
counterexamples (e.g. trimmed-down, dedicated purpose interactive
desktop systems, or scripted servers that do more sophisticated things
with GnuPG, like secret key management, network access, etc).

> And imho, it is an upgrade regression to change the meaning of
> `bin:gnupg` from `provides /usr/bin/gpg` to `high-level collection of
> local and networking cryptography tools`.

Thanks for reporting this.  I hear your frustration but i think the
meaning of the gnupg package has traditionally meant "able to use GnuPG
in all contexts".  As upstream GnuPG has become more modular, simply
installing /usr/bin/gpg will *not work* in scenarios where (for example):

 * the user needs to handle secret keys (this needs gpg-agent)
 * the user needs to interact with the network (this needs dirmngr)

GnuPG upstream also builds a range of tools for other functionality, and
the suite as a whole is known as "GnuPG".

If we want the guidance littered around the web to keep working, then we
need to continue to supply the full functionality.

> Thus please consider making `bin:gnupg' what `bin:gpg' package
> currently is - a minimal provider of /usr/bin/gpg only, for the sake
> of keeping upgrades small. Drop `bin:gpg' package name. And please
> consider make the new package name to be the meta of all the things,
> e.g. `bin:gnupg-all', `bin:gnupg-meta' or some such.

sorry, but i am not convinced that this change is the right thing.  The
"GnuPG" name refers to the GnuPG project.  "gpg" refers to the binary on
its own.  One additional approach would be to have "gpg" refer to just
the binary, "gnupg" refer to "gpg" plus the traditional "gpg-agent" and
"dirmngr", and then some complete "gnupg-all" wihch depends on
everything produced by the GnuPG upstream code, but that makes the
dependency graph even worse, and adds one more package.  I've gotten
enough pushback on the number of packages that i'm not inclined to add
any more, and i don't think the extra complexity that would entail would
be worthwhile.

I'm tempted, frankly, to collapse the package suite still further,
reducing the number of packages in total, but potentially increasing the
number of external dependencies.  See the "GnuPG package split and
interlocking dependencies" thread on pkg-gnupg-maint last September, in
particular:

  http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2017-September/006023.html 

Making the packaging interdependencies even more complex does not seem
like a good thing.

> I understand that this may result in regressions, e.g. if existing
> users of `bin:gnupg' are expecting the full-interactive
> suite. However, interactive users are easier to fix their systems,
> than automated/scripted/cross-distro-version deploys. To prevent
> interactive systems regressing, please consider adding `Recommends:
> gnupg-all` (or maybe Suggests) to the new minimal `bin:gnupg' package.

I think this argument works the other way around.  Having a server by
default upgrade to the more minimal dependency leaves you in the
direction of missing functionality on systems that are harder to repair.
Therefore, it makes more sense to install the full package on upgrades
for systems that used to use the full GnuPG functionality, and allow
those who prefer to prune to prune on their own (as you've described
is already happening above).

Let me know if you have any other ideas that might help to illuminate
the problem space further.  As it stands, i think:

 * you have the ability to declare a dependency on just the parts you
   want (it's fine-grained, so narrowly-scoped tools should be able to
   pick what they want

 * the interdependencies between packages is probably a bit too complex,
   but isn't unmanagable yet

 * upgrades are likely to err on the side of a more complete
   installation, but can be pruned back afterward, if their
   administrators want.

This isn't a great situation, but it's not a particularly bad
equilibrium point between the various tradeoffs.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20180304/cb0b62d1/attachment.sig>