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

Re: Switching g-i from DirectFB to X11 -- image size; library reduction

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
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?


Attachment: signature.asc
Description: Digital signature

Reply to: