Re: Inclusion of kernel version in kernel package names: A followup
Guy Maor <maor@ece.utexas.edu> said:
>
> Your unmet expectations are exactly why you shouldn't mix custom
> installed kernels with debian prepackaged kernels.
Guy, I have been using debian packaged kernel images for several months now.
I install the source package (now kernel-source). I use the debian.rules
script to build my custom kernel and to make a image-1.3.xx-0.deb file. I
install my new kernel with dpkg --install. Everything is hunky-dory. I also
keep image.deb files and source.deb files around for several versions so that
downgrading is simple. I successfully patched source-1.3.64 all the way up to
1.3.97. In my opinion, there is _no_ better way to manage your custom
kernels. If you are doing something different, I suggest that you try this
method, instead of suggesting that image packages are only for newbies.
If this doesn't work for loadlin users, my apologies. Let's extend this
process to work for you, too.
Bill Mitchell wrote:
>
> Perhaps some sort of roll-your-own-kernel kit would be a good idea.
> Something along the lines of a package which would unpack into a
> pre-positioned kernel source tree at /usr/src/linux, such that
> "make config", followed by "make -f debian.rules binary", would
> produce a homegrown installable kernel package.
Bill, you are right. This is the way to do it, and it is already available.
Just install kernel-source from the devel section. You may fiddle with the
debian.rules file to customize version numbering, if you like.
Finally, Manoj, why do you feel that it is necessary to provide a different
scheme than the one I have described (and I am confident many people are
using)? You may have several image and source packages on disk without having
the full-blown trees and muck under /usr/src. You may easily move from image
to image using dpkg, and it updates /vmlinuz and /vmlinuz.old symlinks so
that you always have a fall-back. Furthermore, the /usr/src/linux symbolic
link is not needed because the kernel Makefiles don't depend on that location
anymore. Let's not add features and complexity without a consensus that a
problem or shortcoming really does exist.
--
Jeff Ebert
ebert@pobox.com
Reply to: