Images, apt-get clean and friends

Alexander Sack asac at linaro.org
Fri Aug 6 11:15:11 BST 2010


On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin <dave.martin at linaro.org> wrote:

> On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack <asac at linaro.org> wrote:>>
>   * 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.
>
> It's interesting to note that due to the fact that /usr/share/doc
> contains mostly nearly-empty directories and tiny files, the
> filesystem overhead may be a significant part of the overall
> consumption here - I estimate about 20-30% of the overall space,
> assuming a typical filesystem with 4KB blocksize.
>
> If we have to keep /usr/share/doc/ (for copyright notices and so on),
> maybe it would be feasible to replace each /usr/share/doc/<package>/
> with a tarball?  This would eliminate most of the overhead as well as
> making the actual data smaller.  Since /usr/share/doc/ is not accessed
> often, and not accessed by many automated tools, this might not cause
> much disruption.
>

CCed Martin who probably has thought about this copyright/space dilemma
while implementing the dpkg goody i mentioned above.


>
> [...]
>
> >>
> >>   * 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?
>
> Classifying drivers by bus, and throwing out anything that can't be
> physically connected, such as PCI/AGP/ISA might be an approach here.
> Also, peripherals which can only be connected to on-SoC buses, but are
> not present in a given platform's silicon could be excluded.  We would
> still have to keep a lot though... anything which can be connected via
> USB, for example.
>

Right. I had something like that in mind too and I think it's the safe way
to go for our "standard" linaro kernels. I wonder if we need a
process/policy that says what modules are needed to become an official
"linaro" BSP kernel :).

Also, once we have support for hardware support packs vendors or people that
want to create kernels etc. with even less modules could still do that on
their own.


> A more ambitious solution might be to allow for dynamic installation
> of missing modules, but that's probably a separate project since it
> would impact on the way the kernel is packaged.
>


Personal feeling on this is that we shouldn't go that far in linaro. But I
would like to hear other opinions on this.


-- 

 - Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linaro.org/pipermail/linaro-dev/attachments/20100806/3995196d/attachment-0001.htm 


More information about the Linaro-dev mailing list