On Wed, Aug 11, 2010 at 05:32:24PM +0100, Wookey wrote: > > Making sure that only repos that are actually needed on the target are > listed can help. Does it need src repos? Does it need > universe/multiverse? leaving those out makes a huge difference.
atm, we dont have deb-src lines from what i know. However, we have universe which I suggested in one of the mails from above to be dropped to save > 50% of that space. > > I assume there are no .debs in the apt cache? debotstrap-based > installers leave all the .debs in because they are needed for > second-stage configuration, but I assume we've done the > second-staging by some means or other. (multistrap-based image > creation does not need the .debs for 'second-stage', so this issue > does not arise). > right, we dont ship .deb files in the rootfs. if so, it would be a bug for sure. >> We could use the em-grip tool (or a variant) to repackage our debs to > make smaller images. However the result is not policy-compliant > 'ubuntu', but a new repository of packages containing the exact same > binaries, but less bloat, ontop of which you can install any normal > ubuntu packages which have not had this treatment. That may or may not > be how we want to proceed? It is a sane and effective way to manage > this sort of thing (it is currently trivial to crossgrade Debian to > emdebian-grip and save a load of space, or to use the installer to > install grip instead of normal Debian). We could pull the same trick > for Ubuntu with relatively little effort. Prerequisite for this is to have derived archives first. So let's add em-grip add to our idea list to evaluate for next cycle (assuming we have derived archives by then). Maybe also talk to scott so they can keep doors open for such a feature when implementing that. > > If we want to make smaller images we should certainly look at re-using > some of the emdebian technology and/or mechanisms as it already works > well. agreed; seems like you just volunteered to push our on-disk-footprint spec this cycle? ;-P - Alexander _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev