Bug#233391: Inefficient packaging of arch independent data in package libc6.1

[Steve McIntyre <steve@einval.com>]

Package: libc6.1
Version: 2.3.2.ds1-11
Severity: normal

This is a semi-automated bug report based on scanning the contents of
binary .deb files in the unstable Debian archive.

The libc6.1 packages seem to contain a very large amount of
architecture-independent data in architecture-dependent packages,
specifically data installed under /usr/share. This is wasteful of
mirror space and bandwidth, as we then end up with multiple copies of
this data, one for each architecture. Initial estimates suggest that
several gigabytes of Debian archive space may currently be wasted
because of packages like this.

The way to fix this depends on the layout of your package:

  * Some packages need to have a -common or -doc package split out to
    contain this common data, and the existing packages that need this
    data should then be altered to depend on the new -common or -doc
    package.

  * This package may already be such a -common or -doc package, in
    which case it probably should already be marked as Architecture:
    all in your debian/control file rather than Architecture: any .

  * Maybe the files under /usr/share do not belong there - several
    packages seem to contain data in /usr/share that is definitely
    architecture-dependent. In this case, please move the files into
    the right place.

Policy is quite clear on this point:

http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata

The usage of these packages is currently:
 debsize pkgsize /usr/share %  filename
 4374822  14944        5808 38 pool/main/g/glibc/libc6.1_2.3.2.ds1-11_alpha.deb
 6205082  21484        5848 27 pool/main/g/glibc/libc6.1_2.3.2.ds1-11_ia64.deb

Please split this package appropriately. If you believe your package
is already split reasonably, then sorry for bothering you. If you wish
to discuss this further, please feel free to reply to this bug. If you
agree that there's a problem here but need help to fix it: again, feel
free to ask...

Thanks,
--
Steve McIntyre, Cambridge, UK.                                steve@einval.com