[pkg-gnupg-maint] Bug#814027: Bug#814027: Provide gpgv-udeb from gnupg 1.4 on armel for stretch?

[Daniel Kahn Gillmor]

Hi Martin--

On Sun 2016-02-07 12:23:06 -0500, Martin Michlmayr wrote:
> I'm trying to support a device in debian-installer which only has 4MB
> space in flash to hold the installer ramdisk.  This just broke due to:
>
> gnupg2 (2.1.11-5) unstable; urgency=medium
>
>   * taking over gpgv-udeb from gnupg 1.4 packaging
>
> The new gpgv-udeb pulls in libgcrypt20-udeb and libgpg-error0-udeb.
> The former in particular is huge.
>
> I assume libgcrypt20 is not optional for gnugpg v2.

That's right, GnuPG 2.x depends explicitly on libgcrypt.  GnuPG 2.1.x
(the "modern" branch) is the only place where GnuPG supports more modern
cryptography (including elliptic curves) and is where the bulk of the
active work on GnuPG is taking place upstream.  I'd really prefer it if
stretch was dependent on 2.1.x and only 2.1.x (1.4.x will stick around
as gnupg1 for those people who really need support for bad old stuff
like PGPv3 keys)

As for the libgcrypt-udeb dependency, isn't its size amortized by
cryptsetup's dependency on it as well?

> I'm wondering... is there any way to continue providing gpgv-udeb from
> gnupg 1.4 on armel for stretch?  I don't mind dropping support for
> this device after stretch but it would be nice to support it in
> stretch.  Unfortunately, I cannot think of anything else to drop from
> the ramdisk.  Let me know what you think.  If providing support from
> gnupg 1.4 for stretch on armel is too much of a hassle, I guess I'll
> have to drop support now.

is it possible to reduce the size of libgcrypt20-udeb itself?
Alternately, we could try building gpgv-udeb with static linkage and see
if that lets us cull unused parts of gcrypt to make the overall package
smaller.

One last option would be to make and ship a gpgv1-udeb that could be
adopted by particularly constrained platforms.

        --dkg