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 ?
