Hi, On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis <k...@linaro.org>wrote:
> Hi there! > > I unpacked our minimal release image and ran an xdiskusage on it, > mostly to see what we're shipping -- and I was surprised to see that a > fourth of the image is actually apt package caches and lists. Can we > put into the image generation script something to strip them out before > generating the image? > if there are really .deb's shipped in the tarball then this is definitly waste and a bug. However, if its just the lists and pkg cache then I am not so convinced unless we say we remove apt (and dpkg) from our images (e.g. dont allow easy install/upgrade etc.). Those files would come back when running apt-get update etc., so the only thing we would win is smaller initial download bandwidth, while I think we are really after general/lasting disk foodprint savings. One thing we could do is remove universe from our default apt line. this probably would reduce the size of that directory by > 50% ... Long term we could have our own archive with less packages ... this could reduce size of those indexes etc. even further. > The untarring also suggests a number of places where we could further > trim the image, some of which are probably pretty hard to do: > > * stripping /usr/share/doc out (but everybody knew that) > ack. we plan to do that using pitti's dpkg improvements; last time they didn't land in the archive yet, but I will check the status soon again. > * dropping charmaps, zones and locale info that will never really be > used > I haven't look into those. if we ship useless stuff we should definitly make it go away. Anyone volunteers to look at this aspect a bit closer? > * stripping out modules for devices that won't ever be on > this ARM device > yeah, this feels to make sense. However, I am not sure how to draw the line. Maybe this is something the kernel WG can take a look at and come up with a reduced list of modules? * stripping out firmware for peripherals that won't ever be on this > ARM device > right. this could be part of the modules effort from above imo. -- - Alexander
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
