[pkg-gnupg-maint] GnuPG package split and interlocking dependencies [was: Re: Bug#873499: Should depend on "gnupg | gnupg2 | gpg"]

[Daniel Kahn Gillmor]

On Mon 2017-09-11 11:31:03 -0400, Daniel Kahn Gillmor wrote:
> Upstream's preference is to have all the binaries installed, and gpg
> itself is never even tested upstream without having all the other
> binaries available.

To make the current situation a little bit clearer, i thought i'd graph
the interdependencies of the binary packages currently produced by the
gnupg2 source package.  The legend for these graphs is:

 * box nodes are external or installer-oriented packages
 * diamond nodes are metapackages or transitional dummy packages
 * ellipse nodes are normal packages

 * black arrows are Depends
 * red arrows are Recommends
 * blue arrows are Suggests

The graphs do not show external dependencies.

Here's the current package split:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: package-dependencies.png
Type: image/png
Size: 91372 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170911/e8c14fa8/attachment-0002.png>
-------------- next part --------------

And then i graphed the dependencies of a (not currently implemented)
severely simplified packaging split:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: simplified-package-dependencies.png
Type: image/png
Size: 43668 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170911/e8c14fa8/attachment-0003.png>
-------------- next part --------------

I confess I'm tempted by the simplified packaging proposal here, despite
having only recently (post-stretch) made the more fine-grained split.

The main downside of the simplified proposal seems to be that the gnupg
binary package would be several megabytes in size, which might
discourage some people from installing it.  But systems with the full
gnupg suite installed would actually save space because of duplicated
/usr/share/doc in the non-simplified split.  And we'd get fewer bug
reports about sub-components not being available, and it would lead to
fewer confusion among other contributors to debian about what their
package's dependencies should be :)

I'd love to hear feedback from other people about what they think of
this possibility.  I'm undecided.

     --dkg

( We could make the packaging even more simple by shipping scdaemon
  internally to the gnupg binary package and converting scdaemon itself
  to a transitional dummy package -- this would add a dependency on
  libusb-1.0-0 to the main package, which doesn't seem too horrible)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170911/e8c14fa8/attachment-0001.sig>