On Thu, Oct 18, 2012 at 11:02 AM, Benny Amorsen <benny+usenet(a)amorsen.dk> wrote:
Josh Boyer <jwboyer(a)gmail.com> writes:
> Of course we would. The entire point is to reduce the size, and the
> only way to reduce the size is to build it with different config
> options.
Just splitting off most modules would do the job I would think... Of
course you can go smaller if you change config options, but that is a
lot of work.
Maintaining a list of core modules does not sound like an unbearable
task. (Easy for me to say, of course). Then everything else under
/lib/modules can go into a separate RPM.
Your definition of core modules is going to differ from mine, and the
next persons, and the next.
# rpm -ql kernel-3.6.1|grep ^/lib|xargs du -c
31488 total
# du -s /lib/modules/3.6.1-1.fc17.x86_64/
100324 /lib/modules/3.6.1-1.fc17.x86_64/
Making sure that the right systems get the extra module RPM is left as
an exercise for the reader.
It's not simple. It's not easy. It buys you very very little and it
leaves the maintainers having to continuously guess which package a
module goes into. Then there's the requests to move them from one to
the other.
I'm _very_ against splitting the modules up more than they already are.
The modules-extra subpackage has been somewhat a pain already, and those
are the modules that are very rarely used. Extending it to common ones
leaves me with a headache just thinking about it.
josh