I use make-kpkg to build several versions of a kernel, and this for me is much simpler: edit Makefile and define Extraversion as the date, so today Extraversion=.0209.
If I made more than one version today I could extend it with .020901 or something. This has several desirable consequences: 1. I don't need to screw around with symlinks. Each kernel has a unique name, and the boot loader knows it by that name. In the boot menu kernels are shown in order from newest to oldest. 2. Each kernel has its own /lib/modules tree and I don't need to worry about overwriting an old one before I'm ready -- it's installed or removed along with its kernel. 3. I use grub, so I have configured kernel-package to run update-grub whenever I install or remove a kernel package. I realize this isn't the Official Debian Way, but it works better for me. Kevin On Sun, 9 Feb 2003 19:55:02 +0100 mi <[EMAIL PROTECTED]> wrote: > Since i started compiling different 'flavours' of the same > kernel-version, i also use symlinks. In my case: > in /boot: > 'kernel' pointing to a subdirectory '/boot/kernel-x' where x is a digit > 'vmlinuz' pointing to /boot/kernel/vmlinuz-2.4.18 > 'System.map' poinitng to /boot/kernel/vmlinuz-2.4.18 > ( well this might be not necessary but else there's an ugly log) > and in /lib/modules: > '2.4.18' pointing to '2.4.18-x' > So, what i have to do for make-kpkg is: > pre install: > unlink '2.4.18' to protect the actual modules, and > post install: > move the new 2.4.18 to 2.4.18-(x+1) and create a new symlink > move config-2.4.18, the kernel an System.map into > a newly created subdir kernel-(x+1), and adjust the symlink 'kernel'. > Or better, with a little script that also checks anything is alright and > fiddles out what's to be done, change kernels with a single command > 'kernel -5'. > For the boot-menu, there are two more symlinks 'kernel-recovery' and > '2.4.18-recovery'. > > > If i'd been a programmer, i would try to 'patch' make-kpkg to use a > little config-file that contains paths and the used scheme and its > patterns, to do all the 'handwork' for me, including safety checks. With > options like to run dpkg immediateley after compilation has finished, to > overwrite existing dir's and to tell dpkg if it's lilo.config or a grub > menu.lst - or to ask rather nothing at all, since the symlink system > obsoletes editing those config files. > Ah, the config options could be overwritten by commandline. > Next to think about would be how to hotplug the new stuff on the > fly....;-) > > -- > micha. > > > > Could you explain to me why you need more than two automanaged > > links? What kind of changes you do need to make? It would help to > > perhaps improve kernel-package if I could understand the motivation > > and assess the need for a change in behaviour. > > > > manoj > > btw. how is it expressed correctly, like above or rather symlinking from > target to linkname ? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] >
