Your message dated Sun, 25 Apr 2004 12:30:31 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Inefficient packaging of arch independent data in package
libgcj4
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 18 Feb 2004 02:29:15 +0000
>From [EMAIL PROTECTED] Tue Feb 17 18:29:15 2004
Return-path: <[EMAIL PROTECTED]>
Received: from s2.ukfsn.org (mail.ukfsn.org) [217.158.120.143]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1AtHSc-0005tO-00; Tue, 17 Feb 2004 18:29:15 -0800
Received: from localhost (lucy.ukfsn.org [127.0.0.1])
by mail.ukfsn.org (Postfix) with ESMTP id 86B3AE6D5F
for <[EMAIL PROTECTED]>; Wed, 18 Feb 2004 02:28:10 +0000 (GMT)
Received: from mail.ukfsn.org ([127.0.0.1])
by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 24183-13 for <[EMAIL PROTECTED]>;
Wed, 18 Feb 2004 02:28:10 +0000 (GMT)
Received: from mail.einval.com (unknown [80.46.37.4])
by mail.ukfsn.org (Postfix) with ESMTP id 20D0EE6D50
for <[EMAIL PROTECTED]>; Wed, 18 Feb 2004 02:28:10 +0000 (GMT)
Received: from sledge.mossbank.org.uk ([10.13.0.5] ident=mail)
by mail.einval.com with esmtp (Exim 3.35 #1 (Debian))
id 1AtHSa-0004LC-00
for <[EMAIL PROTECTED]>; Wed, 18 Feb 2004 02:29:12 +0000
Received: from steve by sledge.mossbank.org.uk with local (Exim 3.36 #1
(Debian))
id 1AtHSa-0004uL-00; Wed, 18 Feb 2004 02:29:12 +0000
To: [EMAIL PROTECTED]
Subject: Inefficient packaging of arch independent data in package libgcj4
Message-Id: <[EMAIL PROTECTED]>
From: Steve McIntyre <[EMAIL PROTECTED]>
Date: Wed, 18 Feb 2004 02:29:12 +0000
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_02_16
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no
version=2.60-bugs.debian.org_2004_02_16
X-Spam-Level:
Package: libgcj4
Version: various
Severity: normal
This is a semi-automated bug report based on scanning the contents of
binary .deb files in the unstable Debian archive.
The libgcj4 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
3772818 11712 4388 37 pool/main/g/gcc-3.3/libgcj4_3.3.3-0pre3_arm.deb
4665592 19776 4388 22 pool/main/g/gcc-3.3/libgcj4_3.3.3-0pre3_ia64.deb
4061992 12180 4388 36 pool/main/g/gcc-3.3/libgcj4_3.3.3-0pre3_m68k.deb
4399840 13452 4388 32 pool/main/g/gcc-3.3/libgcj4_3.3.3-0pre3_s390.deb
4032628 12940 4388 33 pool/main/g/gcc-3.3/libgcj4_3.3.3-0pre3_sparc.deb
4295746 17204 4388 25 pool/main/g/gcc-3.3/libgcj4_3.3.3-0pre4_alpha.deb
3979320 12480 4388 35 pool/main/g/gcc-3.3/libgcj4_3.3.3-0pre4_i386.deb
4133892 13248 4388 33
pool/main/g/gcc-3.3/libgcj4_3.3.3-0pre4_powerpc.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. [EMAIL PROTECTED]
---------------------------------------
Received: (at 233393-done) by bugs.debian.org; 25 Apr 2004 10:34:14 +0000
>From [EMAIL PROTECTED] Sun Apr 25 03:34:14 2004
Return-path: <[EMAIL PROTECTED]>
Received: from mail.cs.tu-berlin.de [130.149.17.13] (root)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BHgxh-0008O3-00; Sun, 25 Apr 2004 03:34:14 -0700
Received: from bolero.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.19.1])
by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id MAA13382
for <[EMAIL PROTECTED]>; Sun, 25 Apr 2004 12:30:32 +0200 (MET DST)
Received: (from [EMAIL PROTECTED])
by bolero.cs.tu-berlin.de (8.12.10+Sun/8.12.8/Submit) id i3PAUVcX020200;
Sun, 25 Apr 2004 12:30:31 +0200 (MEST)
From: Matthias Klose <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 25 Apr 2004 12:30:31 +0200
To: [EMAIL PROTECTED]
Subject: Re: Inefficient packaging of arch independent data in package libgcj4
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-2.0 required=4.0 tests=BAYES_00 autolearn=no
version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
X-CrossAssassin-Score: 1
According to upstream (Michael Koch?) some byte compiled classes are
OS dependent (not necessarily architecture dependent).
