Re: kernel-{image,headers} package bloat
On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > Unless you care about performace. Which is the main reason to use
> > different packages for each CPU type.
>
> I compile my own kernels, and have for a long time. But it's a pain to
> go through all the poorly-documented options and takes quite a while
> to select those options and actually build a kernel. And then there's
> the times I have to go back and recompile because I left out my mouse
> drivers, or ide-scsi, or vfat. It's entirely rational to want to pick
> up the 10% improvement from hitting the right button in dselect and
> not worry about the 20% from recompiling the kernel.
in that case, a far better solution is a package containing a bunch
of pre-generated kernel .config files, plus a menu script to copy
your choice to the right subdirectory (e.g. /usr/local/src/linux or
wherever)...then run "make menuconfig" or "make xconfig" to let you
tweak the .config before compiling.
that would be one package, taking maybe a few hundred kilobytes total.
call it kernel-helper and make it depend on kernel-package.
problem solved.
btw, if you've been compiling your own kernels for a long time then you
probably do somthing similar to what i do - copy in the .config from the
previous version and run "make oldconfig" before "make menuconfig" and
make-kpkg. i've been doing this for years and it's a great way to manage
kernels. i even make copies of the .config files which are specific to
particular machines.
for example, if i want to compile 2.4.2 for a machine called foobar
and i have a previously saved .config for 2.2.17 for that machine
then i copy it into /usr/local/src/linux, run "make oldconfig", "make
menuconfig", and then build the kernel with make-kpkg...and finally copy
it to the right machine with scp.
similar, if machine barfoo is very similar to machine foobar then i
might use foobar's .config as the base for creating barfoo's .config.
perhaps doing this is not completely obvious to new users. in that
case, we should be teaching them that this kind of thing is possible,
educating our users to make effective use of the existing tools.
we have good tools for managing kernel .config files and kernel
versions. kernel-package is an outstanding piece of work...manoj has
done some lots of other cool work too, but this by itself is more than
enough to earn a great deal of respect.
if users don't know that this exists or don't realise how useful it is,
then that can be solved with education.
craig
--
craig sanders <cas@taz.net.au>
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Reply to: