Frans Pop <elen...@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.
signature.asc
Description: Digital signature