[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#648755: lintian: arch-dep-package-has-big-usr-share is probably to eager.



On 2011-11-14 Luca Niccoli <lultimouomo@gmail.com> wrote:
> Package: lintian
> Version: 2.5.3
> Severity: normal

> Dear Lintian maintainers,

> my package splix triggers the following lintian check:

> I: printer-driver-splix: arch-dep-package-has-big-usr-share 2498kB 97%
> N: 
> N:    The package has a significant amount of architecture-independent data
> N:    (over 4MB, or over 2MB and more than 50% of the package) in /usr/share
> N:    but is an architecture-dependent package. This is wasteful of mirror
[...]
> while it is true that most of the package is architecture independent, it
> also happens to be extremely compressible (ppd files).
> The one and only binary package splix has weighs about 150K.
> I don't think the overhead (both for human and archives) of splitting away
> the an architecture independent part of the package is worth the little
> saving in space.
> The lintian check is probably simplistic in that it assumes that a relatively
> big disk usage in the installed systems implies a big disk usage for the
> archives.
[...]

Just too add my vote:
Lintian definitely measures the wrong thing if it looks at the
uncompressed size. Mirror space and bandwith are influenced by the
(currently xz-)compressed size.

I also think that the lintian threshhold of 2 MB uncompressed is too
low. Nowadays I would expect something like at least 3 MB compressed
or even higher.


Splitting a package has some cost which needs to be taken into
account:
It takes up maintainer time and adds complexity with potential for
additional bugs. The newly split off packages will need descriptions
which will need to be translated.

The list of packages and their description is still an important part
of Debian's UI. Users will browse over available packages and search
through them, trying to find software matching their needs. Having
"junk" like foo-data in there makes this harder.

Increasing the number of packages slows down updates due to increased
size of the Packages file (less relevant with incremental updates) and
it also slows dows apt/aptitude.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


Reply to: