[Pkg-gnupg-maint] Bug#592902: Bug#387688: Add gnupg as apt dependency in Squeeze to be able to solve #387688 in Squeeze+1?

[Carsten Hey]

* Philipp Kern [2010-08-15 13:30 +0200]:
> On Fri, Aug 13, 2010 at 01:37:15AM +0200, Carsten Hey wrote:
> > currently apt depends on debian-archive-keyring which depends on
> > gnupg. It has been proposed to remove the latter dependency in
> > #387688, this would save about 5 MB of disk space in a sid
> > debootstrap.
>
> I'm still not sure if I buy this argument.  After all it would leave
> the debootstrap without apt (which is the current default behaviour,
> I know).

In the meantime apt has been added to base packages for debootstrap's
buildd variant.

> How useful is this, really?

My wording was not as clear as it should have been :)  Neither apt's nor
debian-archive-keyring's dependencies influence the size of a Debian
chroot with only essential and build-essential packages installed.

I was talking about a rather minimal Debian installation _with_ apt.
Two examples for such installations are the chroot environments created
by the debootstrap variants minbase and buildd.


Let's look into this in more detail:

Currently the "Installed-Size:" of apt and its non-"Required: yes"
dependencies is 12,624 (6,904 + 5,720) kB:

    apt                       5,244
    libstdc++6                1,204
    debian-archive-keyring       60
    gpgv                        396  (required for verifying signatures)
    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯  ¯¯¯¯¯
    needed dependencies       6,904


    gnupg                     5,176
    libusb-0.1-4                 96
    libreadline6                356
    readline-common              92
    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯  ¯¯¯¯¯
    superfluous dependencies  5,720

By removing the (currently indirect) apt dependencies on gnupg and
libusb-0.1-4 and making apt depend on gpgv (or gpgv | gpgv-tiny)
instead, 5272 kB could be saved.  There are ways to accomplish this for
Squeeze+1, how it could be done seems to be nothing that needs to be
discussed before Squeeze is released.

To save additional 448 kB by removing the dependency on libreadline (of
course not by default, but only if the user chooses this) there seem to
be two ways:

 * Build a new package gpgv-tiny, configured with --without-readline.
   gpgv-tiny without gnupg-tiny would be pretty useless unless apt and
   debian-archive-keyring remove their gnupg dependency.  If the gnupg
   maintainer decide to build gpgv-tiny, it should IMHO be done after
   apt's gnupg dependency has been removed.

 * Teach gpgv to dlopen() libreadline and use it only if it is available
   (suggested by Florian Weimer in #592902).  Using dlopen would have
   obvious advantages, but this would require adding a patch to the
   Debian package unless it would be accepted upstream.

As explained, the minimal disk usage of apt and its non-essential
dependencies could be dropped easily from currently 12,624 to 6,904 kB.
After Debian's possible future switch to Tdeps it would be 3,119 kB.


There are ways to further reduce the disk usage of a nearly minimal
Debian installation without requiring the user to do the work
her/himself and without negatively influencing a non-minimal
installation.  Reducing disk usage about a half megabyte or two
megabytes is not much, but many small reductions combined lead to
significant less disk usage.

An imaginary debootstrap variant 'tiny' that, e.g., would install
debconf-english instead of debconf-l18n (this saves 1,516 kB) and
gpgv-tiny instead of gpgv, that would not need to install gnupg and so
on, could create such a minimal installation plus apt.  This combined
with the biggest saving of disk usage, having tdebs in Debian and not
installing them, would lead to a rather small but usable Debian chroot.


> What's the use case?

The obvious use cases are:

  * Installation on systems where disk space is limited.

  * People with slow or traffic limited internet connections would be
    happy to save traffic when they create a build chroot or similar.

Being able to create small but usable Debian chroots could also lead to
less obvious use cases being more reasonable than they are now.  One
possible example is creating an unstable chroot just to run a single
program not available in stable.


> (Still your other remarks look sane, and AFAIK a dependency on gnupg
> has been committed into apt.)

Yes, the dependency is already in experimental.


Regards
Carsten