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

Re: Are we monitoring disk space per package over time anywhere?

On Sat, 03 Sep 2011 11:48:28 +0200
Steffen Möller <steffen_moeller@gmx.de> wrote:

> Hello,
> with more people using Debian on phones and SSDs, the size
> of packages keeps being an issue. 

It's more than the packages themselves. It also includes the Packages
file and there's a clear need to encourage maintainers to use more
package splits.

Emdebian has smaller packages and keeps the Packages file smaller by
only providing a subset of all packages in Debian.

There is a possible issue where Debian might consider splitting main
by functionality as well as by freedom but Emdebian has tried that with
our Component support and it proved too difficult to manage in the long

Other issues include:

0: single binaries which need upstream support to split up
1: over zealous dependencies / recommends
2: package selection - maintainers / upstreams need encouragement to
package smaller apps with smaller dependency chains *and leave them
small* which leads on to:
3: resisting feature creep. This includes closing some bugs as wontfix
when what is needed is another small tool instead of the existing tool
becoming twice the size.

> And some claim that there
> would not be much difference of current distros to all the
> overhead that Redmond brings.

Depends if you can live without Xorg - not all graphics need libx11.
> Are we monitoring any sudden in- or decrease in disk
> space per package or "per tasksel" anywhere already?

The closest we get is the DebianCD team. There are many other factors
which affect whether any particular package is considered "too big". A
small package with a nightmare dependency chain is as much of a problem
as a big package which only depends on libc6. Small python apps
(especially GUI ones), many perl packages, panel applets too - it's
surprising how often a small package generates links into massive
dependency chains. I try to gauge some of these problems by installing
problematic packages in an empty pbuilder chroot - not the -dev
package, the runtime, starting from only what is part of


Neil Williams

Attachment: pgphMhyiuIPo8.pgp
Description: PGP signature

Reply to: