Hi Frans, thanks for your feedback on this. On Fri, Feb 19, 2010 at 07:46:37 +0100, Frans Pop wrote: > 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? > > IIUC libgpg-error0 contains error messages. Somehow I doubt their display > would ever be relevant for D-I. > All X needs is an SHA1 implementation, which is likely a very small part of libgcrypt. It doesn't have to be libgcrypt, but I picked that one for the main deb because 1) it doesn't come with openssl's license headaches, and 2) it's already part of the debian base system. The udeb could use a different implementation if necessary. > 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. > > * disable every option in X and libraries that the installer does not need > I'm thinking of things like 3D and acceleration. > Already done, afaik (not sure if that was in the images you tested, but http://git.debian.org/?p=users/kibi/pkg-xorg/xorg-server.git;a=shortlog;h=refs/heads/pu/udeb-clean removes most of the unused stuff from the X server udeb). > * library reduction > Currently only libc, libnewt and libslang get reduced. Library reduction > was something that was absolutely required for floppy-based images, which > explains why relatively small libs like newt and slang are included. > > For libc the reduction is temporary: only for the initrd and early > installation stages. During "anna" we load the full libc-udeb as other > components loaded during anna will need symbols not included in the > reduced version. > But for libs exclusively used by cdebconf (like newt and slang) the gain is > permanent as we can be certain no additional symbols will be needed later, > so there's no need to load the full versions later. This means it also > helps reduce memory usage for the full installation. > > 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]. > I'm pretty sure libx11 would benefit from this, as it has some code that's not used by anything, but has to stay for ABI reasons. I believe its locale data could be stripped down as well, somehow. Can't speak for gtk and glib as I'm not familiar with those. > 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). > > > Some things that might need thinking about: > > - Maybe gtk could benefit from a stripped-down flavour instead of > > using the 'shared' one; that might lead to depending on fewer X > > libraries; other patches (gtk2-engines, rootskel-gtk come to mind) > > might need tweaking in this case, so as to use the proper .pc > > file. There's a few X extensions that are optional in gtk, so disabling those could be tried. That would allow removal of the corresponding X client libs as well. Would be interesting to know how much this saves. > > - Maybe libgpg-error and libgcrypt11 could be replaced by > > libcrypto0.9.8-udeb (already used by openssh). One downside is that > > libcrypto0.9.8-udeb is bigger. > > These are definitely worth thinking about. Wild thought: could the openssh > udebs be made to use libgcrypt instead? > No. Cheers, Julien
Attachment:
signature.asc
Description: Digital signature