Perhaps fitting. Kernel compilation can be a real pain in the ass, especially if you forgot to do a make modules_install on a machine on a remote network, or forget that you have drivers that are outside the kernel tree, such as your NVidia graphics card drivers, that you need to compile as well.
Debian provides a framework for managing this. The kernel-package provides the capability to make a debian kernel-image package for you. Here's some basic instructions -- although I recommend you read the kernel-package docs too, as they are pretty good.
This will create a .deb for you, but before you do this you have to decide if you want to set a revision number or a version tag. The revision number is basically the version of this package. Use --revision N to set it. You should use revision 1 for the first kernel package you build for each version. When you update the package (perhaps to add in an option you forgot the first time) simply increment the revision and recompile.
You can also set a version tag. This goes in the 'EXTRAVERSION' field of the kernel version. If you have installed a pre-packaged kernel for most distributions before, you'll have seen this. Eg: 2.4.18-bf24, one of debians install kernels, has the EXTRAVERSION tag of 'bf24'. More importantly, the extraversion is reported in 'uname -r' output, and is also used to locate the modules for the kernel (they reside in /lib/modules/`uname -r`/ ). If you change the EXTRAVERSION for every kernel you build, you dont run into problems with the module tree still existing, or wanting to be overridden.
For example, I use an EXTRAVERSION of "-smp" to indicate that this is an SMP kernel. If I build a UP kernel as an emergency kernel for the OS, I use "-up", and so on. If there are any extra patches I have applied to this kernel, for example the pre-emptive multitasking patch, I mention that: "-preempt". And so on. This basically means you can keep track of what features a kernel has, simply by checking its extraversion tag - or its .deb package name
Use the '--append-to-version' command in make-kpkg to set this: --append-to-version=-smp
Finally, to get make-kpkg to build this kernel you give it the target of 'kernel_image'. This creates a .deb with the kernel image, system map, config file for the kernel, and the kernel modules tree. When you install the .deb, if you set up your /etc/kernel-img.conf correctly it'll even configure your bootloader for you.
make-kpkg -revision=1 --append-to-version=-smp kernel_image
Another feature of make-kpkg is that it will build .debs for any module sources you have installed that are outside the kernel tree. The condition is that they must exist in /usr/src/modules - which is the case if a debian source package existed for them. One example of this is lm-sesnors.
The lm-sensors-source package contains the file /usr/src/lm-sensors.tar.gz. If this is untarred, it extracts into /usr/src/modules/lm-sensors/. If you specify the 'modules_image' target, it'll build the kernel modules out of all subfolders in /usr/src/modules and create .deb package for each tree (eg, lm-sensors in this case) built against the kernel you are configuring
If you are building kernel packages for your own private repository to use on more than one machine, or you have a single base configuration that you need to compile for multiple architectures or flavours of machine then you probably want to make use of the Debian kernel package architecture instead of using make-kpkg directly.
There is a good HOWTO on doing this at http://kernel-handbook.alioth.debian.org/index.html