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

Fri Mar 2 17:59:53 UTC 2018

Package: gnupg
Version: 2.1.21-4
Severity: important

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Maintainer,

In version, 2.1.21-4 the semantic meaning of `bin:gnupg' package has
changed. Previously, if one only needed signature verification tools
one would use `bin:gpgv', if one needed to operate on keys/keyrings one
would use `bin:gnupg' and if bells-and-whistles are required, one
would installed `bin:gnupg-agent', `bin:dirmngr' and so on.

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.

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.

Instead, these systems get the new-meta `bin:gnupg' which pulls in a
lot of high-level dependencies, e.g. LDAP, heidmal stack, sqlite3, and so
so-on.

Thus debootstrapping a min-base chroot/container, on Ubuntu, currently
results in:

I: Found additional base dependencies: adduser dirmngr gnupg-l10n
gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm
gpgv libapt-pkg5.0 libasn1-8-heimdal libassuan0 libcomerr2 libffi6
libgmp10 libgnutls30 libgssapi3-heimdal libhcrypto4-heimdal
libheimbase1-heimdal libheimntlm0-heimdal libhogweed4
libhx509-5-heimdal libidn2-0 libkrb5-26-heimdal libksba8 libldap-2.4-2
libldap-common libnettle6 libnpth0 libp11-kit0 libreadline7
libroken18-heimdal libsasl2-2 libsasl2-modules-db libseccomp2
libsqlite3-0 libstdc++6 libtasn1-6 libunistring0 libwind0-heimdal
multiarch-support pinentry-curses readline-common ubuntu-keyring I:
Checking component main on http://ftpmaster.internal/ubuntu...

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.

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.

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`.

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.

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.

Regards,

Dimitri.