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

Reply via email to