Frans Pop <elendil@planet.nl> (19/02/2010):
> Why image size is important
> ---------------------------
> 1) every MB pushes other packages off the 1st full CD and DVD This
> may not seem like a major issue, but it's something that causes the
> debian-cd team headaches. The space on especially the first CD is
> at a premium. We've always aimed to have the 1st CD install a
> working desktop environment *and* support the server tasks. There
> are other images where we either aim to keep as small as possible,
> or where we try to fit different arches or desktops together. In
> some cases it's a tight fit. And even if it does fit in itself an
> increase may e.g. push packages needed to support specific languages
> off an image.
While I can understand the ultimate goal, I'm not sure saving a few kB
here and there is going to make such a difference in the end. (As you
noted in a xulrunner bugreport, Recommends can drag a little bit more
than what's exactly needed…)
> 2) makes loading the image for netboot installs slower
Okay.
> 3) reduces portability
> Some arches (sparc, arm netbooks) have limitations on the size of
> the image that can be loaded.
Okay.
Anyway, netboot-gtk was only enabled for i386, amd64, and powerpc,
IIRC. Maybe the next one could be enabled for more archs if we keep
the size low enough to meet the size limitation?
> Why memory usage is less important
> ----------------------------------
> We do have a lower limit for the graphical frontend coded into
> rootskel-gtk, but that is only so that systems that have e.g. 64 MB
> (and thus can handle the G-I initrd size, but not run the graphical
> frontend) will gracefully fall back to the newt frontend instead of
> crashing.
Alright, just had a look at the memory requirement for the X11-based
image since this 64MB bar was mentioned on IRC.
> How image size could be reduced
> -------------------------------
> In general: many small savings can add up to a significant reduction.
>
> * try to avoid some dependencies altogether
> Two udebs I noticed are libgcrypt11 and libgpg-error0; together 250
> kB. Is the first really needed? If it is, maybe a lot of algorithms
> could be disabled?
I tried to do so, but the final size didn't go down as expected.
Moreover, it seems like every algorithm is quite tied to libgpg-error
calls, so I couldn't really get rid of it there.
> IIUC libgpg-error0 contains error messages. Somehow I doubt their
> display would ever be relevant for D-I.
I didn't dig in that direction, see below.
> Also note that for udebs static compilation of libs is an option
> that can be (carefully) considered [1]! This will automatically
> reduce size as well as only used symbols will be compiled in.
Julien pointed me to libmatrixssl (which is much smaller than openssl,
and easier to dig into). It already ships a static library with the
needed symbols for X11: matrixSha1{Init,Update,Final} (interested
folks may want to read render/glyph.c in xorg-server). Unfortunately,
the headers shipped in libmatrixssl1.8-dev don't make it possible to
tweak xorg-server to use those functions.
If that doesn't sound to bad, I could:
- Provide a patch against libmatrixssl1.8-dev so that it ships the
appropriate headers, maybe in a special location so as to avoid
cluttering the usual include paths
(/usr/include/libmatrixssl/onlyforthebrandnewshinyXudeb)
- Patch xorg-server a bit more so that the main build happens against
libgcrypt and so that the udeb build happens against this new
libmatrixssl version, building statically against it.
- Profit.
The second step isn't ready yet, but I already have Xorg built against
libmatrixssl (for both flavours as of now). According to debdiff, the
Depends on libgcrypt11-udeb goes away, and the final size for the
xserver-xorg-core-udeb doesn't seem to grow up too much:
| Installed-Size: [-2012-] {+2032+}
I couldn't really test this image as much as I would have wanted,
since udev got uploaded lately, leading to my local udev udebs being
ignored in favour of the new ones. → No keyboard and no mouse in X,
but at least, X starts properly, and glyphs are displayed properly.
Which I assume is what I needed to check.
> * disable every option in X and libraries that the installer does not need
> I'm thinking of things like 3D and acceleration.
I also have a patch for gtk's configure.ac, so that we can try and get
rid of extra X libs, which should save more bits. I haven't tried it
yet, that's probably my next step.
> * library reduction
> […]
> So IMO we should now look at library reduction for the largest
> "extra" libs used in the graphical installer: libgtk, libglib,
> libx11. I think a huge reduction should be possible, possibly even
> making the image smaller than the current directfb based one [2].
>
> Library does complicate D-I releases as it currently means the libs
> will be taken from the host system at build time (to ensure a
> version match with the .pic file used in the reduction).
I'm not sure I'm going to dig into this at this point, but that sounds
like a worthwhile goal given their respective contribution to the
image size.
I guess that finalizing the set of udebs needing work is the most
important thing to do right now; then finalizing the patches against
all of them; then lowering the overall size by optimizing
(e.g. through lib reduction). What do you think?
Mraw,
KiBi.
Attachment:
signature.asc
Description: Digital signature